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PARTIAL LIST OF SUPPLIERS 

Most fieldbuses or control system communication networks 
that have reached the stage of international or industrial stan- 
dards are supported by user groups who maintain Internet 
sites. These sites contain lists of products and suppliers. For 
the systems covered in this section, the following is the list of 
products and suppliers: 

AS -Interface (www. as-interface.com) 

HART (www.hartfoundation.com) 

PROFIBUS (www.profibus.org) 

FOUNDATION fieldbus (www.fieldbusfoundation.org) 
ControlNet (www.odva.org) 

MODBUS (www.MODBUS.com) 

Ethernet/IP (www.odva.org) 

INTRODUCTION 

It has been 15 years since the authors first contributed to the 
Instrumentation Engineers Handbook (IEH) with an article 
on networks in process automation (PA). In the last revision 
in 2001, we noted that the increase in computing power and 
the advance of Internet had caused significant changes in 
PA with respect to the situation in 1995. Much has changed 
since then as the advances in the IT world continue to make 
a major influence in PA. 

In the meantime, system safety has also become an issue, 
particularly in the chemical and petrochemical industries. 
The publication of standards on safety instrumented sys- 
tems (SIS) for the process industry by both the International 
Electrotechnical Commission (IEC) and International 
Society of Automation (ISA) has prompted the development 
of a number of network safety protocols as well as the manu- 
facture of process instrumentation conformant to specific 
safety integrity levels. 

Finally, wireless has become an important tool. Interest in 
wireless solutions for the process industry has been encour- 
aged by developments in mobile/cell telephone networks and 


the increasing use of wireless communication between com- 
puters and their peripherals. Cabling has always been a cost 
factor in the process industries, and wireless networks appear 
to offer an economical solution. At the time of writing, two 
theoretically compatible network protocols for process/fac- 
tory automation are in the process of standardization. Other 
wireless protocols have also found use in simple wireless 
communication tasks. 

This chapter discusses, among other things, the impact 
of recent developments on PA. It looks at the use of networks 
within a production company, the models used in digital 
communication, and the technologies and hardware that form 
the basis of all networks. An overview of the communication 
protocols of interest to PA is also included — most of these are 
covered in greater detail in the sections to follow. 

ENTERPRISE ASSET MANAGEMENT 

Before taking a closer look at the physical aspects of net- 
works, it might pay to ask what part they play in a modern 
production facility. Ten years ago, a control system was 
seen as a self-contained process, the information generated 
being largely confined to the system itself. More often than 
not, the commercial and technical management of a facil- 
ity were separate entities, with little interchange of informa- 
tion between the two. This began to change for two reasons: 
firstly, it was realized that efficient production was not just a 
matter of optimizing the control system; rather all aspects of 
production, from purchasing of raw materials to selling of the 
finished product, had to be considered. Secondly, Ethernet 
technology began to appear at control level, making inter- 
change a viable possibility. 

The publication of ANSI/ISA S88 [1] in 1995 and the 
essentially equivalent international standard IEC 61512-1 [2] 
in 1997 was the first step toward a holistic view of production. 
Addressing the problems of batch control, where there was 
difficultly in integration, configuration, and formulating user 
requirement, the standard defines a physical model, proce- 
dures, and recipes as well as the associated terminology. Of 
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note is the physical model, which proscribes a plant hierarchy 
of enterprise, site, areas, process cells, units, equipment mod- 
ules, and control modules. The enterprise, site, and unit are 
mandatory; the other levels are optional. A glance at any con- 
trol system engineering tool will show how well this “logical” 
view has established itself, and more often than not, the struc- 
ture will also be reflected in a “physical” view of the arrange- 
ment of the control equipment, that is, the associated network. 

The recipe content was also standardized. Now machine 
interpretable instructions could be sent by a supervisory sys- 
tem to the controller, which would then change the system 
parameters ready for the next batch. Since batch planning has 
a strong commercial aspect, the necessity of a vertical com- 
munication path between the control and office network soon 
became apparent. So did the need for IT security, since open- 
ing the production network to the office world also makes 
it vulnerable to unauthorized access, for example, from 
Internet hackers. 

In 2000, Part 1 of the ANSI/ISA-S95 standard series [3] 
on enterprise control was published, followed by the equiva- 
lent IEC 62264-1 in 2003 [4], At the time of writing, five 
parts have been published by the ISA, with a further one in 
development; three parts have been published by the IEC. 
The standards set out to specify an open automated interface 
between enterprise and control systems. They have been 
developed for global manufacturers and can be applied in 
all industries and all processes. They address not only batch, 
continuous, and repetitive production processes but also 
material management, maintenance, and the planning of 
human resources. In fact, they are a blueprint for what today 
is often termed “enterprise asset management” (EAM). 

Enterprise asset management can be defined as: “the 
whole life optimal management of the physical assets of an 
organization to maximize value.” An interdisciplinary activ- 
ity, it extends across the whole life cycle of a facility, from its 
conception, construction, and commissioning, through oper- 
ation and maintenance, to its decommissioning or replace- 
ment. It applies to plant, equipment, and facilities, relying on 
the open exchange of information throughout a facility irre- 
spective of its origins. This, in turn, means the vertical and 
horizontal integration of systems that, in the past, were oper- 
ated independently. Last but not least, the networks carrying 
this information must be open, reliable, robust, and secure. 

INFORMATION REQUIREMENT AND FLOW 

What information is required to run a plant efficiently and 
how does it flow? Figure 2.1 shows a typical information flow 
within a company producing, for example, chemicals, min- 
erals, food, or beverages. For simplicity, the activities have 
been allocated to three levels: 

• Control 

• Plant management 

• Enterprise management 


Activities at the control level could be said to be data based. 
Those at plant management are predominately information 
based. At enterprise level, the available information is ana- 
lyzed and decisions are made upon it, resulting in a down- 
ward flow of information back to the plant and hence to the 
control level. 

Control 

At the lowest level, manufacturing and process control, a 
number of production steps may be involved, for example, 
batching, mixing and reaction, drying, conveying, and pack- 
aging or storing. Normally each step will be individually 
controlled. Raw data pass from the field to the controller in 
the form of process and state variables, for example, pres- 
sure, temperature, level, and flow. The controller acts upon 
the information, returning control variables to the field for 
valve actuators, drives, switching equipment, etc. For PA, 
the signals are normally a mixture of analog and binary, for 
factory automation prominently binary. Here “analog” and 
“binary” are used in the sense of “continuously variable” and 
“discrete” and do not refer to the way in which the signal is 
transmitted. 

Depending upon the type of instrument used, alarms and 
events may also be generated in the field. Many measuring 
instruments supporting a digital communication protocol are 
able to monitor their output signal against four alarm limits, 
changing the accompanying signal status accordingly when 
the limits are violated. Similarly device events, for example, 
over-range conditions or maintenance requirement, can be 
transmitted over the network. For conventional systems, that 
is, those with no digital communication, the alarming is done 
in the controller or the supervisory control and data acquisi- 
tion (SCADA) software connected to it. 

The control itself does not require a communication net- 
work as such — the majority of processing plants today still 
use analog signal transmission, for example, 4-20 mA or 
pneumatic signals, to communicate between the field and the 
controller and vice versa — but operation and management of 
the plant does. Connections to a central host and peripher- 
als, for example, the control room, local monitoring consoles, 
etc., are done either by a system-specific communication 
backbone or an open, Ethernet-based network. The more 
information this network receives from the field, the better 
quality of control and the easier it is to optimize production. 

Plant Management 

The primary task at plant management level is the operation 
of the plant. Today, the majority of plants are operated from 
SCADA software, which visualizes the plant and allows 
operator intervention. SCADA systems may be open, that is, 
use standardized interfaces to communicate with the control 
system, or closed. Nowadays, most open SCADA systems 
use object linking and embedding (OLE) for Process Control 
(OPC) technology, acting as clients to OPC servers operating 
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FIG. 2.1 

Information flow within a company. 


in conjunction with the controllers. Since it is often desir- 
able to have local operating consoles in different parts of the 
plant, today’s systems also act as OPC servers, which can 
be accessed by SCADA clients via the plant network or web 
clients via an Internet browser. Development is now at a stage 
where the plant can be viewed and operated from a palm 
computer or cell phone and short message services (SMSs); 
voice messages and e-mails can be sent from the SCADA 
software to cell telephones and computers. Although the 
SCADA application still resides in the plant network, its 
influence extends far beyond. 

SCADA software also offers functions for maintaining 
and tracking plant performance. Many applications include 
an alarm management system, which displays both inter- 
nally and externally generated alarms and events. Similarly, 
data from the field can be collected and displayed as trends, 


historical trends, or simply be archived for future reference. 
Equally important is the ability to generate reports giving 
a snapshot of the plant status at regular intervals or on the 
occurrence of a particular event. These functions are impor- 
tant not only for the continuous analysis of plant performance 
but also for postmortems on quality issues, which might sur- 
face long after a product has been manufactured and sold. 
Traceability depends upon the availability of relevant data, 
and given the amount of data generated by the average plant 
within the course of a year, any SCADA worth its salt must 
interface with the most powerful databases applications 
available. These are applications that also find use in the 
commercial world, so once again, SCADA software is oper- 
ating beyond the limits of the normal plant network. 

The second important task at plant management level 
is the maintenance of the plant, which once more benefits 
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from more information from the field. Knowing the state of 
health of plant equipment, vessels, pipes, etc., by regularly 
monitoring key performance factors using information pro- 
vided by the instrumentation that is fitted to them may still 
be in its infancy, but this will be a major growth area of the 
future. Valves already provide a large amount of diagnosis 
information, which can be used to optimize performance and 
predict when they require maintenance or are about to fail. 
An increasing number of measuring instruments also provide 
predictive diagnosis, which can be used, for example, if fail- 
ure of the device in service would lead to a safety risk or 
loss of production. Even if the device is not part of a predic- 
tive maintenance strategy, the ability to see whether a signal 
is good or bad and to pinpoint the cause of failure leads to 
savings in maintenance effort. Such information is evalu- 
ated by maintenance programs, which may make use of an 
independent data collection mechanism. With the develop- 
ment of e-business, there also is a call for automatic order- 
ing of replacement equipment, an action that requires the 
presence of device identification data within the company 
administration. 

Another important maintenance task, particularly in reg- 
ulated industries where systematic proof of the performance 
of quality critical devices must be furnished, is the regular 
calibration of instrumentation. Whether performed in line, 
at the workbench or at an external location, the actual cali- 
bration is only part of the challenge. The need to schedule 
the activities, arrange with the production personnel to make 
plant available, and then plan the resources and mobilize the 
technicians is often more time consuming and challenging. 
Finally, the results must be documented and archived in a 
manner that ensures their traceability at some future date. 

An increasing number of plants are turning to software 
tools to manage and implement calibrations. These are 
designed to operate with calibration rigs that are not perma- 
nently connected to a plant network, but which can communi- 
cate with the host application to transfer the calibration data. 
As calibration may entail a change in device parameters, it is 
important that there is an interface between the calibration 
tool and any maintenance and/or asset management tool in 
use in the plant. Only in this way, the maintenance of several 
databases, with the associated risks and costs of data incon- 
sistency can be avoided. 

Enterprise Management 

From the administrative point of view, the scheduling, moni- 
toring, and maintenance of production will be in the hands of 
a production planning department. This makes its decisions 
based on data supplied by other departments, for example, 
order entries for the finished product, product inventories, 
etc. Before production can start, it must also be ensured that 
sufficient quantities of raw materials for a particular recipe 
are at hand. 

Inventory management, both inbound and outbound, is 
an area where raw data, in the form of level measurement of. 


for example, liquids and/or bulk solids, are essential to com- 
petent decisions. If the inventories are managed in-house, 
some measurements may be available from the control net- 
work. Increasingly often, however, the inbound inventory 
will be managed by the vendor of the raw material and the 
producer himself will manage the inventories of his custom- 
ers. To work efficiently, the inventory data must be up-to- 
date, that is, remote access to measurement data on foreign 
tanks is required. This raises questions of network security. 
One solution is the acquisition of data from a central server 
that is hosted externally or located on the customer’s site. The 
inventory data are polled either on request or at regular inter- 
vals and sent to the server via an Ethernet, telephone or global 
systems for mobile (GSM) communication connection. From 
there, they can be directly integrated into enterprise resource 
planning (ERP) applications such as SAP and Oracle: a case 
in which field data are integrated into the enterprise level, by 
extending the communication network. 

Another case in point is energy management. A great deal 
of energy is wasted in a modern plant, quite simply because 
until quite recently, it was not a significant factor within the 
overall operating and maintenance costs. Wastage is not 
restricted to heating and refrigeration: water, air, and elec- 
tricity consumption must all be monitored to ensure efficient 
use. The tools for creating and analyzing energy balances are 
provided by ERP systems. The data once again originates at 
field level and since the required measuring points are often 
quite different from those for process control, a separate net- 
work or parallel access is often called for. Transmission from 
field to enterprise level will depend on local conditions, but 
again Ethernet, telephone, and GSM networks can be used to 
bridge the gap. 

It can be seen, therefore, that the information provided 
by field devices is required not only for control, but also for 
administrative tasks. The more that field data are used at 
enterprise level and the better their integration, the easier it 
becomes to make the right decisions when running the plant. 
The old adage “first measure, and then control” should per- 
haps now read “first measure, and then manage!” 

COMMUNICATION MODELS 

The idea of having a company-wide information network 
is not new. Computer-integrated processing (CIP), as it is 
known, was first conceived over 30 years ago and is strongly 
connected to the open system interconnection (OSI) layer 
model (see the following text). Over the years, CIP devel- 
oped from the notion of controlling plant procedures with a 
mainframe computer to the vision of the complete exchange 
of data between all levels of the production and administra- 
tive process. Today, it is closely linked with the concept of 
the digital factory. Essential to the success of any network is 
the reliable acquisition, presentation, and timely processing 
of data in all parts of the organization. This, in turn, requires 
open communication throughout the company network. 
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Communication Hierarchy 

Figure 2.2 shows a typical communication hierarchy to be 
found in a production plant. This traditionally comprises five 
levels: field level, I/O level, process control level, plant con- 
trol, or human machine interface (HMI) level, enterprise, or 
corporate level. Please note that there are other ways of clas- 
sifying the information flow and control. Figure 2.1 shows 
a case in point: for the purposes of illustrating informa- 
tion flow, the field level, I/O level, and control level can be 
grouped together. 

The five-level hierarchy model remains a convenient way 
to describe the equipment required to build a network and 
although it is somewhat out of date, it still reflects the struc- 
tures found in many production facilities. Modifications are 
necessary, however, when fieldbus devices are used. In this 
case, the controller, remote I/O, low-voltage switchgear, and 
field devices form a subsystem, so that traditional differences 
between control, I/O, and field levels become blurred. This is 
still more so, when Foundation Fieldbus devices, which are 
able to drive control loops, are used. 

The pyramid shape is also not representative of the effort 
and cost at the various levels. The enterprise level is just as 
extensive as the field level, although the majority of appli- 
cations running on it will be standardized. The HMI and 
control levels require programming effort, although this has 
been reduced considerably by the introduction of standard- 
ized client-server interfaces. For control systems based on 
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FIG. 2.2 

Factory communications hierarchy. 


analog (4-20 mA) and binary signals, the integration effort 
is negligible, but the cables/conduits are a considerable cost 
factor. For fieldbus-based control systems, there are savings 
on cables, but a certain amount of integration effort is essen- 
tial to correct operation. Despite these shortcomings, how- 
ever, the pyramid provides a simple overview of how data 
should be exchanged, even if the physical reality is somewhat 
different. 

Network Requirements 

The demands placed on data transmission within a company 
network change according to the position in the pyramid (see 
Table 2.1). At enterprise level, normal office programs, for 
example, text processing, spread sheets, databases, e-mail 
will be in use together with ERP applications, such as SAP 
and Oracle. The prime use of the network is to allow clients 
to call up or store data from a central server. Thus it is not 
in constant use, but has to handle relatively large amounts of 
data that are not time-critical in the sense being subject to a 
strict schedule. On the other hand, users expect data to be at 
hand almost instantaneously, so that high transmission rates 
are a must. 

At the field, I/O and control level, the opposite is true: 
the network is constantly in use, the response times and 
data packets must be relatively short and communication 
must be deterministic. In manufacturing, where there is a 
high degree of sequential control, high transmission speeds 
and very short signals are at a premium. In contrast, in pro- 
cesses where temperature, level, etc., are used for control, the 
speed is less critical, but the signal must contain more status 
information. When fieldbuses were first conceived, a further 
distinction was made between the path from the controller 
to the “interface device” and the “interface device” to the 
field device, partly from consideration of chip costs, which 
explains why so many bus protocols support two different 
transmission rates, for example, PROFIBUS DP and PA or 
FOUNDATION fieldbus HSE and FI. 

The HMI level must handle both types of data. Archiving, 
visualization, and maintenance programs are in regular con- 
tact with the control level, scanning and mapping selected 
process data. There is also the need to change device config- 
urations online. On the other hand, there are often exchanges 
with the enterprise level, for example, computer aided design 
(CAD) data, computer numerically controlled (CNC) pro- 
grams, recipes, and spread sheets with plant data. There is 
also the same demand for client-server services as on the 
enterprise level. 

This variety of applications means that no single net- 
work protocol can operate efficiently at all levels. The proto- 
col defines the principle network characteristics such as the 
speed of data transmission, length of data packets, degree of 
data security, the method by which data are distributed, etc. 
Thus, in a brewery, for example, the beer production will use 
a protocol suitable for process control, whereas the bottling 
and packing facility will use one more suited to automated 
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TABLE 2.1 

Fieldbus and Management Level Data Characteristics 

Data Type 


Feature 

Graphics 

Data 

NC Programs 

Clock Signals 

Process Values 

Alarms 

Response time 

1-100 s 

1— 100s 

1-100 s 

1-100 ms 

20-100 ms 

0.1-80 ms 

String length 

>10 kbit 

1 — lOkbit 

>10 kbit 

8-64 bits 

clOkbit 

8-64 bits 

Frequency 

Seldom 

Very seldom 

Very seldom 

Very frequent 

Frequent 

Seldom 

Time 


Uncritical 



Critical 



Source: Electronics, February 1990. 


manufacturing. Information from both systems will be 
required at the plant management and enterprise levels. 

In order to promote efficient data exchange between net- 
works as well as between devices on the same network, there 
is a need for standardization. Standardization ensures that 
the devices on a particular network work together and that 
there is transparency between the various levels of the com- 
munications hierarchy. The central pillar of all network stan- 
dards is the so-called ISO-OSI reference model. 


OSI REFERENCE MODEL 

The OSI model [5] was first published in 1984 by the 
International Standards Organization (ISO) in order to bring 
uniformity and transparency into the development of com- 
munication network standards. It defines a communication 
model applicable to all network devices, from mainframe 
computers operating at enterprise level to simple actuators in 
the field. It makes no attempt to make physical specifications. 
Instead it provides a framework in which existing and future 
communications standards can be placed. 

The OSI model splits the communication process into 
seven functional levels or “layers” (see Figure 2.3 and Table 
2.2) each of which performs a clearly defined task. By defin- 
ing the function of each layer with respect to those above 



Layer 7 
Layer 6 
Layer 5 
Layer 4 
Layer 3 
Layer 2 
Layer 1 


TO. 2.3 

ISO-OSI communications model. 


and below, the model ensures the compatibility of all devices 
using a particular network protocol, and between one net- 
work protocol and another. Above Layer 7 is the application 
process that requests or receives transmissions and which 
may be an office program, a controller, a database, a SCADA 
program, a workstation, a sensor or actuator, etc. This so- 
called Layer 8 or “User Layer” is not part of the standard. 

The seven layers can be further classified into two func- 
tional groups. Layers 1-4 serve the network and are set the task 
of transporting data from one part of the network to another. 
Layers 5-7 serve the application and must present the trans- 
ported data in an understandable form to the user of the net- 
work, for example, a sensor or a SCADA program. The layers, 
and the terms, definitions and standards associated with them, 
are discussed in more detail in the following subsections. 
Readers requiring more detailed information are also referred 
to Thompson [6]. 

OSI Implementation 

There are three OSI implementations that are of historical 
interest to the development of today’s network standards: 
MAP, TOP, and ETA-MAP/Mini-MAP 

The first OSI implementation was the manufacturing 
automation protocol (MAP), developed in 1983 by General 
Motors and standardized in IEEE 802.4 (wide band, token 
bus). It supported data exchange on a wide area network, 
defined all seven OSI layers and found use in factory auto- 
mation. Around the same time, Boeing was developing the 
technical office protocol (TOP) for use in technical scientific 
and office automation environments. It lays emphasis on the 
exchange of CAD/CAM documents, graphics, and text. This 
was Ethernet based (IEEE 802.3) and supported a range of 
transmission media and access methods. It was combined 
with MAP in MAP Version 3.0 at the start of the 1990s. As a 
result, many vendors of automated manufacturing equipment 
began to offer MAP interfaces. 

Of more interest to fieldbuses is EPA-MAP. Shortly after 
the publication of MAP, the need was recognized for a simi- 
lar standard to cover the requirements of local networks. Here 
devices are equipped with identical or very similar operating 
systems. Data coding is either nonexistent or very simple, 
there is no requirement for a transport layer, and connections 
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TABLE 2.2 

Layers of the OSI Model 


Layer 

Function 

Tasks 

Examples: Standards/Realizations for Fieldbuses 

Layer 7 

Application 

Provides the user with specific network 
commands and functions 

Dynamic host configuration protocol (DHCP), Simple network time 
protocol (SNTP), Simple network management protocol (SNMP) 

Layer 6 

Presentation 

Encodes the application layer data before 
forwarding it for transmission and 
decodes incoming data before forwarding 
it to the application layer 

Not relevant to fieldbuses 
Advanced Encryption Standard (AES) 

Layer 5 

Session 

Synchronizes communication sessions 
between two applications 

Not relevant to fieldbuses 

Layer 4 

Transport 

Prepares the data string for transmission 
and ensures that it is reliably exchanged 

Transmission control protocol (TCP), User datagram protocol (UDP) 

Layer 3 

Network 

Selects the data route and ensures that the 
network is not overloaded 

Internet protocol (IP), Time Synchronized Mesh Protocol (TSMP) 

Layer 2 

Data link 

Establishes and maintains connection 
between two participants 

IEEE 802.2, Token passing 

IEEE 803.3, CMSA/CD, IEC 61158/PROFIBUS PA: Master-slave, 
IEC 61 158/FF: Bus arbitration (LAS), Time Division Multiple 
Access (TDMA) 

Layer 1 

Physical 

Puts the data on the physical medium and 
takes it off at its destination 

Bell 202 (FSK), EIA RS-232, EIA RS-422, EIA RS-485, IEC 
61 158-2, 100BaseT (IEEE 802.3u), Wireless (IEEE 802.15.4, 
2.4 GHz Band) 


within the network do not have to be sought. These consider- 
ations lead to the idea of enhanced performance architecture 
(EPA), which provides less powerful, but far more efficient 
communication than MAP. In addition, it is particularly 
suited to real-time applications. EPA describes a method, 
added later to the OSI model, in which only the application, 
data link, and physical layers are used for data communica- 
tion. This method is also known today as Mini-MAP and 
forms the basis of many fieldbus protocols. If protocols from 
other layers are required, they are stacked as an application 
interface at the top of the data link layer. 

Wireless networks differ, in that they require the net- 
work layer in order to manage the entry to, operation of, and 
departure from the network. A number of Internet protocols 
are also of considerable interest to modern control systems. 
These include the transmission control protocol/Internet pro- 
tocol (TCP/IP) and user datagram protocol/IP (UDP/IP) data 
transport protocols and several protocols for file management 
and time distribution in the application layer. Internet is par- 
ticularly interesting because it is market driven. This means 
that developments are rapidly adopted and incorporated into 
the Internet Official Protocol Standards, which are controlled 
by the Internet Activities Board. Since Internet preceded the 
original OSI standard, which anyway did not address the pos- 
sibility of connecting networks together, it does not follow 
it. Later editions of OSI, however, were adapted to include 
internet aspects. 

Control and Fieldbus Protocols 

It can be seen from Table 2.3 that there are quite a number of 
standard protocols used in control networks that are within or 


accepted as being part the OSI framework. A control network 
protocol is characterized primarily by its physical and data 
link layers. The data link layer may be further subdivided 
into two sublayers, media access control (MAC) and logical 
link control (LLC). The MAC sublayer is responsible for the 
addressing and sharing of the network, the LLC sublayer for 
the coding and decoding of the information as well as flow 
and error control. 

The physical layer often defines the transmission 
medium, mode, transfer rate, extent of the network, etc. The 
method chosen for MAC is of particular interest to process 
control systems (PCS), because it also influences the size and 
extent of the network, the time when refreshed information 
is available to the network participants, and the determinism 
of the system. 

Until recently, control network standardization at the 
application layer was less advanced. For this reason, there is 
less openness, and many control protocols are proprietary at 
this level. Table 2.4 lists those that are included in the IEC 
61158 standard as well as other fieldbus protocols of inter- 
est to PA. “Industrial Ethernet” protocols are not included 
in the table, since at the time of writing there are almost 30 
different flavors. Differences are to be found both in the data 
link layer in the way the determinism is imposed and at the 
application level. For example, devices running ControlNet 
TCP/IP and Modbus TCP/IP will not understand each other 
if operated together on the same network. 

Of those protocols included in IEC 61158, only 
PROFIBUS-DP, FOUNDATION fieldbus, and ControlNet 
can really be seen to be of interest to PA. They also enjoy 
a great deal of multi-vendor support. Using this criterion, 
Modbus, which is not included in the IEC 61158 standard, 
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TABLE 2.3 

Attributes of Various Interface Standard 





Attributes 

RS-232C 

RS-422 

RS-485 

IEC 61158-2 

100BaseTX 

Maximum devices 

1 transmitter, 

1 transmitter, 

32 transmitters/ 

32 transmitters/ 

Limited only by 


1 receiver 

16 receivers 

receivers 

receivers 

address range 3 

Signal coding 

±12V pulses 

Differential 

Differential 

Manchester II 

8B6T 

Topology 

Star 

Bus 

Bus 

Bus 

Star 

Maximum line length (m) b 

15 

1200 

1200 

1900 

100 

Number of lines 

Minimum 3 

4 

2 

2 

4 

Maximum rate of 
transmission 

19.2 kbit/s 

10 Mbit/s 

10 Mbit/s 

37.5 kbit/s 

100 Mbit/s 

Communication mode 

Duplex 

Duplex 

Half-duplex 

Half-duplex 

Duplex 

Transmission type 

Asynchronous 

Asynchronous 

Synchronous 

Synchronous 

Synchronous 

Connectors 

9- or 25-pin 
connectors 

Not specified 

Not specified 

Not specified 

RJ45 connectors 


a There is a practical limit determined by the response time of the system. 
b The maximum line length is dependent upon transmission rate and application. 


must also be seen as a quasi-standard, which may run on a 
variety of physical layers, since this is not part of the specifi- 
cation. Similarly Highway Addressable Remote Transmitter 
(HART), with its enormous installed base, has long been an 
industrial standard. Field devices also exist for AS-interface 
and Ethernet/IR 

It can be seen that both PROFIBUS and FOUNDATION 
fieldbus offer a second open protocol for the field level and, 
although strictly speaking, proprietary, ControlNet and 
DeviceNet often stand in a similar relationship. This is in 
accordance with the original concept for a fieldbus stan- 
dard, which foresaw a high-speed (H2) network at control 
level and a low-speed (HI) network at field level. The change 
in speed necessitates an interface between H2 and HI net- 
works, which may also bridge a change in physical layer. 
Thus, FOUNDATION fieldbus changes from high-speed 
Ethernet to IEC-61 158-2 and PROFIBUS from RS-485 to 
IEC 61158-2. Although FOUNDATION fieldbus HI and 
PROFIBUS PA devices could be physically operated on the 
same segment, the data link layer differs, and the devices are 
unable to understand each other. 

Wireless Networks 

Wireless networks differ from wired networks in that there 
is no physical connection between the participants, although 
the base station, that is, the device collecting the incoming 
data, normally has a wired connection to a host application. 
As far as process engineering is concerned, two technolo- 
gies are of interest, WirelessHART [7] and ISAlOO.lla [8], 
both of which are on the way to becoming international and 
national standards, respectively. At the time of writing, a 
third technology, supported by the Chinese, has also been 
put forward for standardization. Another technology that 
might be found in the plant is ZigBee [9], which enjoys much 
support in building automation. Bluetooth [10], which offers 


solutions for short-distance, peer-to-peer wireless communi- 
cation, is also to be found. A typical application is the use of a 
Bluetooth/HART modem between a field device and a “hand 
held” palm computer. Table 2.5 summarizes the attributes of 
the various wireless protocols. 

Both WirelessHART and ISAlOO.lla use the same physi- 
cal layer, IEEE 802.15.4 [11], which supports operation in the 
2.4 GHz ISM band. Since a wireless signal is not as robust as a 
wired or optical signal, measures must be taken to ensure that 
interference, in the form of other radio signals in the same 
band or objects moving between transmission paths, does not 
cause the network to collapse. To this end, both standards 
use the time- synchronized mesh protocol (TSMP) devel- 
oped by Dust Networks [12], which has built-in safeguards 
that ensure reliable and secure communication. The services 
provided by TSMP cover the requirements of the transport, 
network, and data link layers of the OSI model. The network 
comprises so-called “motes” or wireless devices, which may 
be field devices, wireless adapters/routers, or a base station. 
The base station hosts the network management and security 
application. The devices form a mesh network, which is self- 
organizing and self-healing, redundant paths being provided 
when obstacles or interferences interrupt communication. 

TSMP devices are synchronized with each other and 
communicate in time slots. In practice, this means that the 
transmitters awake for periods of scheduled communica- 
tion and sleep for the periods in between. As a result, there 
is a very low power demand. This is particularly true of 
WirelessHART devices operating in multi-drop mode, where 
only 4 mA is required to power the device. Reliable operation 
is ensured by using so-called frequency hopping spread spec- 
trum (FHSS) channel hopping and direct sequence spread 
spectrum (DSSS) phase modulation. In FHSS, the channel 
frequency is changed at regular intervals according to a hop- 
ping pattern known by the network participants. For DSSS, 
the signal is modulated pseudo-randomly with a continuous 
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TABLE 2 A ^ 


Attributes of Various Control and Fieldbus Standards 








Nodes a 


Segment Length 

Bus Safety 


Protocol 

Standard 

Industry 

Special Features 

Processing 

Medium Access 

(Max) 

Medium 

(Max) 

Concept 

Further Information 

Ethernet 

IF.F.F. 802.3 

Office, 

Most widespread network 

Decentral 

CSMA/CD 

30 b 

100BaseT4, 

100m 

None 

Industrial Ethernet 



factory. 

protocol 




copper 



Association www. 



process 





lOOBaseFL, 

3000 m 


industrialethemet.com 








fibre optics 
100BaseTX, 

100m 










copper 




FOUNDATION 

IEC61158, 

Factory, 

Function blocks for 

Decentral 

CSMA/CD 

30 

Copper or 

Maximum 500 m 

None 

Fieldbus Foundation 

fieldbus HSE 

Type 5 

process 

decentralized control 




fiber optics 




FOUNDATION 

IEC61158, 

Process 

Function blocks for 

Central/ 

Token passing 

32 

Copper 

1900 m 

Exd or 

www.fieldbus.org 

fieldbus H 1 

Type 1 


decentralized control 

decentral 





Exi 


PROFINET 

IEC 61158, 

Factory, 

Isochronous real-time 

Decentral 

CSMA/CD 

30 

Copper or 

500 m 

None 

Profibus International 


Type 10 
IEC 61784 

process 

PROFIenergy 




fiber optics 



www.profibus.com 

PROFIBUS DP 

IEC 61158, 

Factory, 

Optimized for remote I/O 

Central 

Token passing 

126 

Copper or 

1200 m (copper). 

None 



Type 3 

process 





fiber optics 

several 

kilometers with 
optical fibers 



PROFIBUS PA 

IEC 61 158, 

Process 

Standard certification 

Central 

Master-slave 

32 

Copper 

1900 m 

Exi to 



Type 3 


process for hazardous 






FISCO 





areas 






model 


Interbus 

IEC 61158, 

Factory 

Optimized for remote I/O 

Central 

Single master with 

256 

Copper 

13 km 

None 

Interbus Club www. 


Type 8 




synchronized 
shift register 





interbusclub.com 

ControlNet 

IEC 61158, 

Factory 

Optimized for factory 

Central 

TDMA 

99 

Copper 

6 km (with 

None 

ControlNet 


Type 2 


applications 




(coax) 

repeaters) 


International 











www.controlnet.org 

Modbus 

Industrial 

Process 

Simple structure, widely 

Central 

Master-slave 

247 

Copper 

1200 m 

None 

Modbus users website 


standard 


used 







www.modbus.org 

DeviceNet 

EN 50325 

Factory 

High immunity to 

Decentral 

CSMA/CD 

200 

Copper 

500 m 

None 

ODVA www.odva.org/ 




electromagnetic 

interference 




(4-wire) 




AS-Interface 

EN 50295 

Factory, 

Power over bus, for 

Central 

Master-slave 

124 

Copper 

100m 

None 

AS-Interface 


IEC 62026 

process 

simple actuators and 







Association www. 


Part 2 


sensors 







as-interface.net/EN 

HART 

Industrial 

Process 

Integrates into existing 

Central 

Token passing 

16 

Copper 

3000 m dependent 

Exi, Exd 

HART Communication 


standard 


3-20 mA systems 





upon number of 

or Exe 

Foundation 


devices www.hartcomm.org 

a Number of nodes that can be physically connected per segment: in some cases, the number of logical addressable nodes can far exceed this number. 
b Practical guideline for control networks: the more nodes there are the longer the refresh time of the system. 
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TABLE 2.5 

Attributes of Various Wireless Interface Standards 

Attributes 

WirelessHART 

ISA SP 100.1 la 

ZigBee 

Bluetooth 

Application 

Process automation 

Process automation, 

Smart energy, building 

Consumer 



factory automation 

automation 


Physical layer 

IEEE 802.15.4; 2006 

IEEE 802.15.4; 2006 

IEEE 802.15.4; 2003 

IEEE 802.15.1 

Media Access 

TDMA 

TDMA, CSMA 

TDMA 

TDD 

Encryption 

AES 128 

AES 128 

AES 128 

Proprietary 

Anti-interference 

Frequency hopping 

Frequency hopping 

Frequency agility (ZigBee PRO) 

Frequency hopping 

Band 

2.47 GHz 

2.47 GHz 

2.47 GHz; 900 MHz 

2.47 GHz 

Transmission rate (kbit/s) 

250 

250 

250; 20 

750 

Topology 

Mesh 

Mesh, star, cluster 

Mesh, star, cluster 

Star 

Device type 3 

FFD 

RFD, FFD 

RFD, FFD 

Master, slave 

Maximum distance 

200 m outdoors; 

75 

10; 75 

10 

between nodes (m) 

50 m indoors 




Maximum number of nodes 

250 (65,000) b 

250 (65,000) 

65,000 

8 

Latency (ms) 

4 

10 

10 

>40 

Power rating c 

Very low 

Very low 

Very low 

Low 

Fieldbus support 

HART 

Multiple protocol support 

— 

— 


a FFD, Full Function Device; RFD, Reduced Function Device. 
b Two hundred and fifty devices is a practical limit. 

c The actual power required for the device depends upon the number of times it must transmit per unit time. 


string of pseudo-noise code signals. Since both transmit- 
ter and receiver know the PN sequence, the signal can be 
“unspread” by the receiver and the information it carries 
retrieved. If a foreign transmitter broadcasts at the same time 
and in the same band but with a different or no PN sequence, 
its signal is spread across the spectrum and merges with the 
background noise. In addition to the physical security, both 
WirelessHART and ISAlOO.lla encrypt all signals using the 
Advanced Encryption Standard (AES128) for code manage- 
ment and authentication. 

With so many common features, the question asked 
by users and vendors alike is why are there two stan- 
dards? Originally, the ISAlOO.lla committee was charged 
with drawing up recommended practices for the use and 
deployment of wireless within industry. Their brief, there- 
fore, covered both factory and process automation. Since 
the requirements, for example, for an assembly line differ 
significantly from those for a processing line, the num- 
ber of ISAlOO.lla use cases is much greater than that for 
WirelessHART. As WirelessHART was considered by 
many system manufacturers to be too limited in scope and, 
at the beginning, proprietary in nature, they pushed for an 
ISAlOO.lla standard. ISAlOO.lla therefore supports several 
communication protocols at the application level and allows 
either carrier sense multiple access (CSMA) or time divi- 
sion multiple access (TDMA) for medium access control. 
WirelessHART supports only TDMA. When it emerged that 
the two standards would be incompatible, a great deal of 
pressure by the ISA membership forced the creation of a sub- 
committee, ISA100.12, which was charged with converging 
ISAlOO.lla and WirelessHART “at sometime in the future.” 
In September 2007, the HCF offered the ISA an unrestricted. 


royalty-free copyright license, allowing the ISA100 com- 
mittee access to the WirelessHART standard. At the time of 
writing, it is still uncertain whether this has been achieved, 
although trials to assess the interoperability of ISAlOO.lla 
and WirelessHART, initiated by a potential user, will begin 
shortly. If they prove to be incompatible, the user will be 
again forced to choose between competing technologies, as 
most vendors have decided to support only one of the two 
technologies until the situation is clarified. 

PROCESS NETWORK FUNDAMENTALS 

The two OSI layers that have the most influence on the physi- 
cal implementation of the network are the physical and data 
link layer. The first determines the extent and number of par- 
ticipants, the second the arrangement and roles of the par- 
ticipants regarding access to the medium. A glance at Tables 
2.3 and 2.4 shows that the interface standard has a consider- 
able influence on the physical capabilities of the network and 
the fieldbus protocols offer a number of different solutions to 
media access, which are explained more fully in the follow- 
ing subsections. 

Transmission Medium 

The backbone of all networks is the transmission medium, that 
is, the “cabling” that connects the devices. Figure 2.4 shows 
the various types. At field level, the medium is usually copper 
cable, of which there are three main types. Alternatives are 
fiber-optic cables, often used to connect remote I/O and other 
control equipment, and wireless transmission. 
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FIG. 2.4 

Cable types met in control applications. 


Unshielded Twisted Pair (UTP) comprises one or more 
twisted pairs of copper conductors within a protective jacket. 
Its primary use is for Ethernet networks, but they may be 
used to connect up HART devices. Ethernet cables are 
rated according to the EIA/TIA-568 standard [13], whereby 
a Category 5 cable is recommended for transmission rates 
of 100 Mbit/s. Maximum length at this transmission rate is 
200 m. Ethernet cables are often supplied with a RJ-45 male 
connector, in which case they may be crossover for direct 
connection to a computer or straight through for indirect con- 
nection via a switch. 

Shielded Twisted Pair (STP) is similar to UTP cables, but 
the pairs are either shielded individually or share a common 
shield. The shield protects against electromagnetic interfer- 
ence (EMI). STP cables are recommended for fieldbuses: 
they are classed as Type A cables in the IEC 61158-2 physical 
layer standard [14], They should also be used for HART con- 
nections in noisy environments. The maximum length of an 
STP cable depends upon the transmission standard and trans- 
mission rate. Additional restrictions may apply for cables 
connecting intrinsically safe devices in hazardous areas. 

Coaxial cable (Coax) has a solid central conductor sep- 
arated from an outer, tubular braided or foil conductor by 
an insulating medium, all within a protective jacket. The 
shield reduces EMI and acts as the signal reference conduc- 
tor. Coaxial cables are graded according to U.S. Military 
Standard MIL-C-17 with a Radio Guide (RG) number. In 
view of their expense, they are seldom found in the field, but 
might be used in control and computer systems operating at 
higher levels. ControlNet specifies coaxial cables and offers 
a complete range of ancillary equipment. 


Fiber-optic cables are specified as an alternative to 
copper in the Ethernet (100BASE-FL), PROFIBUS DP, 
and FOUNDATION fieldbus HSE standards. Transmission 
rates are higher and, depending upon carrier material, dis- 
tances generally greater than for copper cables. Moreover, 
fiber-optic cables are completely unaffected by EMI and can 
be run into explosion hazardous areas without the need for 
barriers. There have been significant developments in fiber- 
optic cabling systems over the past few years and in addi- 
tion to the classical glass fiber, which bridges distances from 
approximately 3-15 km, depending on thickness, polymer 
fiber optics are now available as a more economic alternative. 
Here, the maximum length between nodes varies between 30 
and 300 m, but since the optical interface modules also act as 
repeaters, the total length is generally much greater. 

There are a number of options for wireless transmission. A 
true wireless network requires that each participating device 
has its own transmitter/receiver. This may be integrated in 
the device or be in the form of a wireless adapter attached 
to it. Transmission is then over wireless local area network, 
one participant, the base station, having a hard wired con- 
nection to the plant network. Another possibility, often used 
for remote monitoring or maintenance is to dial into a public 
telephone or GSM network. The maximum transmission dis- 
tance between nodes for a typical wireless network is 75 m 
(250ft), whereby at least two neighbors should be in contact. 
For GSM it is unlimited, provided contact can be made to a 
provider. 

For an overview of the connectors used in control sys- 
tems, refer to, for example, Barton [15]. 

Topologies 

The network topology describes the way in which the devices 
in the network are connected together. The basic topologies 
are star, ring, bus, and mesh: all other topologies are built from 
these basic elements. Figure 2.5 shows all four together with a 
so-called “tree” structure and a mesh with so-called “clusters.” 
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FIG. 2.5 

Network topologies. 


© 2012 by Bela Liptak 




2 Networks in Process Automation: Hardware Structures and Integration of Process Variables into Networks 51 


A star topology comprises a central device with point-to- 
point connections to all peripherals. The central device con- 
trols access to the network and any data exchanged between 
peripherals must pass through it. If the central device fails, 
the network fails. The failure of individual lines is uncriti- 
cal. The extent of the network is limited by the number of 
connections to the central controller. For hard-wired con- 
nections, shielded cable should be used. As transmission 
interface RS-232C is sufficient; however, in the classic star 
application, a computer system, this is now being displaced 
by the much faster USB or Bluetooth interfaces. Ethernet 
routers and switches are also examples of components oper- 
ating with a star topology. 

In a ring topology, all devices are connected together 
in a physical ring. Decentralized control is required, access 
rights being passed from device to device. If a line fails, the 
network fails, so that bypass switches are required to avoid 
this. The number of participants is unlimited; however, the 
time it takes to circuit the ring sets a practical limit, since 
this governs the response time of the system. The line must 
be interference free, that is, coaxial or other reliable cable is 
required. A special case of a ring topology is that used by a 
multi-master PROFIBUS system. Although the masters are 
not physically connected in a ring topology, they form a vir- 
tual ring, the token (i.e., access rights) being passed from one 
master to another on a strictly deterministic basis. 

In a bus topology, all devices are connected either 
directly or via spurs to a single physical line. Both central- 
ized and decentralized control are possible. Depending on 
control mode, line failure has the same consequences as in 
a star or ring. Failure of individual devices, however, does 
not affect the network function. The number of participants 
is unlimited; however, the time taken to poll all devices sets 
a practical limit. Line must be interference free, that is, STP, 
coaxial, or optical fiber cable is required. 

A tree topology is basically a bus topology with branches 
or so-called “chicken feet,” that is, points where several 
devices are connected to one junction box. It is frequently 
met in PROFIBUS and FOUNDATION fieldbus applications 
where a fieldbus operating at 31.75 kbit/s is connected to a 
high-speed bus via a link or coupling element. 

A mesh topology is characterized by its ability to provide 
redundant paths to a central device (basestation) and is the 
generic topology for wireless applications. Each participant 
may receive information from one neighbor and forward it to 
another. Participants that forward messages are called rout- 
ing nodes, those that do not are called end nodes. Normally, 
the mesh is self-organizing, the available paths being stored in 
routing tables. If a routing node receives no acknowledgement 
of a forwarded message, it uses an alternative path. In order 
to ensure reliable transmission, each routing node must be 
in contact with at least two neighbors. The more neighbors a 
routing node sees and the better their signal quality, the higher 
the integrity of the network. Any routing node seeing only one 
neighbor, or only neighbors with poor signal quality is a poten- 
tial weak link. Whereas the failure or blockage of a device that 


is a weak link may lead to the blackout of entire network sec- 
tions, the failure or blockage of a device in a network of high 
integrity will only lead to loss of its particular data. The num- 
ber of participants is theoretically unlimited, but restrictions 
may be imposed by the protocol used as well as the traffic 
density and response times required by the application. 

A mesh topology with clusters is a mesh with participants 
that also act as masters in their own right within a star or 
bus topology. For wireless networks, the masters could be, 
for example, full function devices (FFDs) and the end nodes 
reduced function devices (RFDs) as per IEEE 802.15.4 [11], 
An example of a star cluster is a participant, which publishes 
its information to a dedicated display or printer; for a bus 
cluster it could be a WirelessHART adapter connected to a 
HART multi-drop bus. 

Although some topologies theoretically allow an unlim- 
ited number of participants, in practice, the associated com- 
munication protocols and transmission interfaces impose 
limits. The design of a network must also take into consider- 
ation other factors such as maximum cable length or distance 
between nodes, where appropriate grounding and, if power is 
taken from the cable, maximum permissible load. 

Transmission 

The digital signals produced by the devices are launched 
onto the network via a transmission interface. In order to 
communicate with each other, all the devices must use the 
same interface, and as such it will be part of any system or 
fieldbus specification. The transmission interfaces of interest 
to control networks are listed together with their attributes 
for copper cables in Table 2.3. 

It is beyond the scope of this section to go into detail about 
how the various interfaces work; however, it can be seen that 
the transmission standard itself often imposes conditions on 
the topology and protocol. Thus, RS-232 can only be used 
in a star topology with one device driving the communica- 
tion. It should also be noted that the line lengths quoted are 
the maximum for the standard. The 1900 m quoted for IEC 
61158-2 becomes 1000m with an intrinsically safe bus and 
the 1200m copper for RS-485 shrinks to 100 m when the 
maximum rate of 12 Mbit/s is required. An explanation of 
the other attributes in Table 2.3 together with a number of 
terms frequently met when transmission interfaces discussed 
are to be found in Table 2.6. Readers requiring detailed infor- 
mation on this and other aspects of industrial communication 
are also referred to, for example, Thomson [6]. 

Logical Link and Media Access Control 

As mentioned earlier, the data link layer provides the tools 
necessary for two or more devices to establish and remain 
in communication. It provides two main functions: LLC 
and MAC. 

The LLC sublayer is responsible fault-free transmission of 
bit streams over the network, calculating various cross-sums 


© 2012 by Bela Liptak 


52 Process Control and Automation 


TABLE 2.6 

Terms and Definitions Associated with Transmission Interfaces 


Attribute 

Alternatives 

Description 

Transmission mode 

Parallel transmission 
Serial transmission 

Byte-by-byte transmission over a minimum of eight parallel lines. High transmission speeds, but 
expensive cables. Used by some buses for automated manufacturing. 

Bit-by-bit transmission over a minimum of one line. The transmission time is dependent upon the 
length of the data string. Often used for fieldbuses. 

Carrier mode 

Baseband 

Broadband 

Carrier signal 

Direct transmission of data without prior modulation. 

Transmission of data by modulating the data on a high-frequency carrier signal. The data can then be 
simultaneously transmitted with other data modulated on a different carrier signal on the same 
transmission medium. 

Frequency in a communications channel modulated to carry analog or digital signal information. 

Signal transmission 

Amplitude modulation 

Frequency and/or 
phase modulation 

The amplitude of the data signal (“0” = low dc voltage or current, “1” high dc voltage or current) 
causes a change in amplitude of a carrier signal, usually an alternating current. 

The amplitude of the data signal causes a change in frequency or phase of a carrier signal, usually an 
alternating current. 

Transmission type 

Asynchronous 

transmission 

Synchronous 

transmission 

Spontaneous transmission of data, requiring agreements on set sequences and types of information 
(protocol). Suitable for smaller blocks of data. 

Transmission requiring that system clocks in both transmitter and receiver are in phase. It allows 
long data blocks to be transmitted efficiently and safely with a high proportion of useful data. 

Communication 

mode 

Half-duplex 

Duplex 

In half-duplex communication, information flows in both directions. First one device transmits: after 
it has finished, the partner answers. 

In duplex communication, information can be simultaneously transmitted and received. 

Transmission rate 

1200 bit/s in steps to 
lOOMB/s 

Indicates how many bits per second can be transmitted between the transmitter and receiver. All 
devices on a network must operate at the same transmission rate. The maximum rate is limited by 
the type of interface and transmission medium used. 


and comparing them to so-called check bits. When a data 
packet is lost or faulty, the data link layer may also have 
the responsibility for retransmitting the message. Another 
function of the data link layer is to add extra data frames to 
the bit stream that contain information about the transmit- 
ter and receiver, the priority of the message, and whether its 
receipt is to be acknowledged or not. Where messages are 
acknowledged, the data link layer may also maintain tables 
of successful Acknowledged (ACK) and Not Acknowledged 
(NACK) transmissions. For wireless protocols, it may also 
allow the blacklisting of channels that prove to be consis- 
tently faulty. 

The data link layer is also responsible for media access, 
that is, the controlled use and sharing of the network by the 
various devices connected to it. There are two distinct meth- 
ods to regulate access: 

• Centralized bus control ( fixed master ): the access to 
the bus by the devices is controlled by a central bus 
master. Examples are the master-slave and the bus 
arbitrator models. 

• Decentralized bus control (flying master ): thanks to 
its intelligence, each device is in a position to con- 
trol the bus itself when it wants to communicate. Two 
examples of decentralized bus control are the token 
passing model as per IEEE 802.2 [16] and the carrier 
sense multiple access with collision detection (CSMA/ 
CD) model as per IEEE 802.3 [17]. 


At field and control level, it is often the case that two meth- 
ods are used together, for example, when several masters 
share the same backbone and communicate in a master- 
slave relationship with their field devices and other control 
equipment. 

Media Access Methods 

Depending on the method used, media access is either deter- 
ministic, that is, communication occurs in a strictly regulated 
manner, or stochastic, that is, a device communicates as soon 
as it has something to say. Strictly speaking, any protocol 
used for process control must be deterministic, but there are 
exceptions. 

When the media is accessed by the master-slave method, 
one bus device is the master: all other participants act as 
slaves. The master alone possesses a continuous right to 
transmit. It polls (or addresses) each bus participant in turn, 
supplies it with data, and/or asks it to transmit its data, for 
example, its measured value and status. To increase the effi- 
ciency, that is, the amount of useful data to overheads, the 
protocol is kept as simple as possible. The security of the data 
depends upon the protocol structure and the error checking 
method used. HART, MODBUS, PROFIBUS DP/PA, and 
AS-i are all protocols that use the master-slave method. 

If the bus arbitration method is used, every device on 
the network may transmit and receive data. The right to 
transmit is organized by a central controller, the so-called 
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bus arbitrator. The arbitrator maintains a list containing the 
order in which and the length of time devices are allowed 
to transmit. The arbitrator works through the list, passing 
the right transmit to each device in turn. If different scan- 
ning frequencies are required, the device can appear more 
than once in the table. It should be noted that although this 
is classified as centralized control, token passing is a central 
element. The method is used in the FOUNDATION fieldbus 
HI protocol. 

The token passing method allows access to the bus to be 
shared between several devices: the token, that is, the right to 
transmit, is passed from device to device. This may be done 
on a master-slave or peer-to-peer basis. In the event of peer- 
to-peer passing, a so-called token ring is built, which may 
be real or logical. The passing sequence depends upon the 
application and is defined during the planning of the system. 
This method allows each device a fair share of the bus, since 
each is allowed to transmit within a preset period of time. 
The time taken to pass the token around the system deter- 
mines the frequency of polling of the individual members. 
Token passing is used by FOUNDATION fieldbus to ensure 
deterministic communication on the HI layer as well as in 
multi-master PROFIBUS systems. 

There are several stochastic or random bus access meth- 
ods of which CSMA/CD is the most well known. All devices 
on the bus have the right to transmit. Each continually listens 
to (or senses) the bus. If this is free, then any of the devices 
can transmit its data. If several devices want to transmit 
simultaneously, a collision is detected and all withdraw. A 
random generator in each of the devices then determines the 
time interval that must elapse before it can attempt to trans- 
mit again. The CSMA/CD bus access method is specified 
in the Ethernet protocol and is used in office networks and 
the higher levels of automation systems. At field and con- 
trol level, for example, in FOUNDATION fieldbus HSE and 
Ethernet/IP protocols, it has to be supported by a centralized 
access management method because there is no strict peri- 
odicity of scanning. This ensures that there are no collisions 
when a device transmits. 

The wireless networks of interest to PA use the time divi- 
sion media access (TDMA) method. Since all nodes must 
access the medium, a means is required that ensures there are 
no collisions. To this end, all nodes share a common sense of 
time, which they constantly check by sending offsets in their 
ACK messages. Each node is assigned a particular time slot 
within a network time frame, in which it is allowed to broad- 
cast. It also keeps a list of parent nodes, that is, those nearer 
to the base station and child nodes, that is, those further away 
from the base station from itself, together with the time slots 
in which they broadcast. A node is only active when sending 
a message to a neighbor, when listening for a neighbor to talk, 
and when interfacing with an embedded sensor or processor. 
The rest of the time it sleeps. The length of the time frame 
determines the response time of the network and the power 
requirement of the node. Faster response times mean shorter 
time frames, less sleep per unit time and hence more power 


consumption. Time slots are measured in milliseconds, how- 
ever, so that in a typical application even router nodes have a 
duty cycle of less than 1%. 

Communication Relationships 

Depending upon the bus protocol, the devices in the net- 
work may stand in one or more communication relationships 
to each other. The relationship determines how the devices 
transmit or receive their data and how the services provided 
by the protocol are implemented. 

In a client-server relationship, the client transmits a request 
to its server communication partner. When the requested 
action is executed and its confirmation is necessary, the server 
issues response to the client. If the client is also a server to its 
communication partner, the relationship is said to be peer-to- 
peer. Otherwise it can be considered to be master-slave. 

In a publisher-subscriber relationship, all the devices 
sense the traffic on the bus continuously. The publisher 
broadcasts its data when it has the right to transmit. The sub- 
scribers to the data recognize that they are of interest to them 
and update their local copies. There is no direct confirma- 
tion of receipt. When communication is controlled by bus 
arbitrator, transfers can be scheduled on a precisely periodic 
basis. Publisher-subscriber is also known as the producer- 
consumer method. 

In a source-sink relationship, a source transmits when it 
detects a necessity to report, for example, an event (and has 
the right to do so). One or more sinks receive the (multicast) 
message, ensuring that the event is detected. One of the sinks 
is responsible for acknowledging the event via a separate 
client-server relationship. 

Table 2.7 illustrates how these three relationships are 
used to distribute information within a FOUNDATION field- 
bus network. 

Network Layers 

The network layer is required neither by “HI” fieldbuses, nor 
by Ethernet itself, which defines only the physical and data 
link layers. It is used by so-called “Industrial Ethernet” or 
“Ethernet TCP/IP,” as well as by other industrial standards 
such as MODBUS TCP and FOUNDATION fieldbus HSE. 
For wireless networks of interest to process control, the net- 
work (and transport) layers are sublayers of the TSMP, which 
also contains the data link layer. 

The network layer is responsible for data routing. When 
the transport layer demands a connection between A and B 
with a specific capacity, it is the network layer that finds a 
suitable route. It must also make sure that the network is not 
overloaded. Where intermediate networks are to be used, the 
data must be stored before it is transferred from one network 
to another. 

The Internet Protocol (IP) is of interest to process control. 
IP is the Internet’s most basic protocol and is used to forward 
data packets. It is a datagram-oriented protocol that treats 
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TABLE 2.7 

Communication Relationships in a 

FOUNDATION Fieldbus Network 


Publisher/Subscriber 

Client/Server 

Source/Sink 

Scheduled 

Unscheduled 

Unscheduled 

Used for publishing data 

Used for operator messages 

Used for distributing event 
notification and trend reports 

Sends parameters between blocks, 

Set point changes, mode changes. 

Sends process alarms to 

for example, the PV value to a PID 

tuning changes, upload/download, 

operator consoles 

control block and operator console 

alarm management 



Access display views, remote 

Sends trend reports to data 


diagnostics 

historians 


each data packet independently. This means that each packet 
contains complete addressing information. Packets can also 
be assigned priorities via a “type of service” held. IP has, 
however, no mechanisms to determine if packets reach their 
destination. Furthermore each packet has a “Time To Live” 
(TTL) held: when the TTL value reaches zero, the packet 
is discarded. The contents of a packet are not checked for 
transmission errors, only the IP header. These functions are 
provided by the transport layer protocols, UDP to a limited 
extent and TCP widely. IP also provides several optional fea- 
tures, allowing a packet’s sender to set requirements on the 
path it takes through the network (source routing), to trace 
the route a packet takes (record route), and to label packets 
with security features. 

For wireless systems, the TSMP provides a number of 
network services. These include self- organization, that is, the 
ability of a node to discover neighbors, measure radio sig- 
nal strength, acquire synchronization and frequency hopping 
information, and establish paths and links with neighbors. 
The data packet includes a network identification number, 
which allows two wireless networks to operate in parallel 
without cross-talk, and join key, which is used in encrypt- 
ing data. Data encryption, normally a job for the presentation 
layer, is done according to the advanced encryption standard 
(AES). 

Transport Layer 

The transport layer is responsible for the interference- 
free transport of data via the various routes and networks 
connecting any two communicating units. According to 
requirement, the transport layer sets up several logical chan- 
nels and chops long information strings into small packets. 
On the receiving side, it reassembles the packets into the 
original string or, if the data is not received in sequence, 
attempts to place them in correct order. The transport layer 
also checks that the data packets have not been falsified 
during transport. Two protocols are of interest to process 
control: 

The Transmission Control Protocol (TCP) runs on top 
of the IP and enables two hosts to establish a connection and 
exchange streams of data. TCP guarantees delivery of the 


data and also guarantees that the data packets are delivered 
in the same order as they were sent. 

The UDP also runs on top of IP. Unlike TCP, it provides 
very few error recovery services. Instead, it offers a direct 
means of sending data telegrams over an IP network. It is 
used primarily for broadcasting messages. 

For wireless systems, the TSMP adds a 32 bit end-to-end 
message identity code to the message for authentication pur- 
poses. This also serves to ensure message integrity, as any 
tampering would alter the code. 

Application Layer 

The application layer defines the services that are supported 
by the network: for instance, read and write commands, 
program management functions, network synchronization, 
addressing, uploading, and downloading of data and virtual 
device images. It is not concerned with the actual carrying 
out of services, but rather with their presentation to the user 
so that he can program the network. The procedures are then 
mapped onto the lower layers. In the full model, the applica- 
tion layer is connected to the lower layers through the pre- 
sentation and session layers. In heldbuses and Ethernet, these 
layers are bridged by special interface programs. Of the vari- 
ous protocols available to the application layer, three find use 
in control applications: 

Dynamic Host Configuration Protocol (DF1CP) is a pro- 
tocol that automatically assigns IP addresses to devices on a 
network every time they connect to it. This means that a new 
device can be added to a network without the need to manu- 
ally assign it a unique IP address. 

Simple Network Time Protocol (SNTP) is a simplified 
version of the network time protocol (NTP), an Internet stan- 
dard protocol that assures accurate synchronization of device 
clock times in a network. Running as a background client 
program on a computer, NTP sends periodic time requests 
to servers, obtaining server time stamps and using them to 
adjust the client’s clock. 

Simple Network Management Protocol (SNMP) is the 
Internet standard protocol for network management soft- 
ware. It monitors devices on the network, and gathers device 
performance data for management information databases. 
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INDUSTRIAL NETWORKS 

Before describing how today’s networks are designed and 
constructed, it is perhaps of interest to look at factory and 
process automation from a historical perspective, since it 
gives us many insights into why certain components, net- 
works, or protocols are designed the way they are. In the 
early days of automation, there were three main areas of use: 
automation of machines in factories, automation of continu- 
ous processes in the petrochemical and related industries, 
and supervision of processes that were distributed at a num- 
ber of remote sites. Each had to separate a solution with typi- 
cal system components: the programmable logic controller 
(PLC), the distributed control system (DCS), and SCADA. 
With the introduction of mainframe computers, followed by 
microprocessors, open protocols, and finally Ethernet, the 
boundaries between the three have now become blurred, and 
elements of all three can be found in a typical network today. 

Programmable Logic Controllers 

In the early 1960s, relay-based machine control was domi- 
nant in factory automation. Hard-wired relay arrays provided 
the logical control for driving a machine. Since the relays 
were not particularly reliable by today’s standards, they had 
to be regularly replaced. This was no problem for small 
machines, but for something like an automobile production 
line, where vast banks of relays were required, it was a night- 
mare. Relay-based control also had the disadvantage that 
the hard-wired logic applied to a particular set of actions, 
and if the product changed, the entire equipment had to be 
replaced. The enormous expense prompted the automobile 
industry in particular to look for alternative solutions. In the 
late 1960s, the first “mini” computers appeared and some 
companies looked to these to provide a solution. In 1968, 
Bedford Associates brought out an alternative solution, a 
Modular Digital Controller (Modicon) 084. Its successor, the 
Modicon 184, became a very successful commercial PLC. 
No longer modular, that is, scalable, the Modicon 184 aimed 
to cover a wide range of applications, so that users could buy 
many individual units to control various machines in their 
factory, but still have the benefit of identical hardware and 
software. This concept is still characteristic of PLCs today. 
The unit was programmed by means of ladder logic, a lan- 
guage that replicates relay-based logic and which aimed to 
make the technician of the day feel comfortable with the new 
technology. 

As microprocessors became more powerful, so did the 
PLCs. The ability to communicate came in 1973 with the 
development of the MODBUS interface. Now, PLCs could 
communicate with other PLCs located elsewhere in the fac- 
tory. Every manufacturer had their own communication 
protocol, however, so systems remained proprietary. With 
communication came the ability to read and write “ana- 
log” values, that is, measurements could be processed and 
with the help of proportional, integral, and derivative (P1D) 


algorithms and set points could be output to actuators. PLCs 
now became interesting for process control. The 1980s saw 
the introduction of the OSI standard, with a subsequent 
improvement in communication: software programming 
from a PC began to replace handheld programmers or dedi- 
cated terminals. The 1990s saw the introduction of fieldbus 
protocols and a gradual reduction of protocols, so that only 
the most popular, for example, MODBUS, are still in use. 
Finally, in the last decade, the programming languages used 
in PLCs were standardized in IEC 61131-3 [18]. 

Today, a typical PLC used for process control comprises 
an input section, a processing or logic section, and an output 
section and will normally be designed to operate with short 
cycle times. It runs a sequential program that has been writ- 
ten for the specific task in hand. During execution, the inputs 
monitor the process and provide information on the events 
and conditions occurring in a controlled process. The logic 
then compares this information to the process state desired 
at a particular instant in time and adjusts its output signals 
accordingly. The valves, pumps, motors, etc., respond to the 
changes in output signal, and the whole cycle starts again. 

The classical PLC has local I/O cards for current, voltage, 
and pulse/frequency signals — any communication between 
controller and I/O is hidden from the user. PLCs fitted with 
a fieldbus interface will normally use a master-slave proto- 
col, such as MODBUS or PROFIBUS. Most PLCs can be 
programmed in any of the IEC 61131 languages, for exam- 
ple, ladder logic, structured text, etc. Applications are often 
stand-alone, that is, requiring no communication with other 
controllers or software tools in the plant. As a stand-alone 
system, connections to configuration and operation tools 
may still be proprietary. Typical PLC applications would be 
the filling and emptying of vessels, blending and mixing, 
as well as dosing and filling. Figure 2.6 shows the typical 
system architecture for a stand-alone PLC. The provision of 
an Ethernet, MODBUS, or PROFIBUS DP port allows the 
PLC to be used with remote I/Os, SCADA software, or be 
part of a controller network. Thus, for instance, a controller 
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FIG. 2.6 

Typical architecture for a stand-alone PLC. 
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using flow meters and valves to control filling quantities, 
could be supervised by the controller responsible for the fill- 
ing machine itself, the relevant commands and data being 
exchanged via the digital communication interface. It is at 
this point where the boundary between a DCS controller and 
a PLC become blurred. 

Since PLCs are relatively simple to program, many man- 
ufactures sell them as “boxes.” The programming is done 
by the customer’s own control and instrumentation depart- 
ment, or if this work is outsourced, by a system integrator. 
Even when the PLC is sold as part of a project won by the 
manufacturer, the programming is seldom done in-house. 
The system is normally maintained by the entity that did the 
programming. 

Distributed Control System 

In the early days of PA, all control was distributed in the 
field (see Figure 2.7). Signal transmission was predominantly 
pneumatic and every control “loop” had its own pneumatic 
controller. Each control loop could be physically seen: the 
measuring device, the air piping going to the controller and 
the air piping going to the control valve. The instrument tech- 
nician, operator, and process control “engineer” were all one 
and the same person. When analog began to replace pneu- 
matic transmission, this situation did not change; the control- 
ler just became analog. 

In the 1960s, mainframe computers made their way into 
company administrative departments. Process control engi- 
neers saw the new technology as a means of controlling their 
plant: every possible control algorithm could be put into the 
computer to enhance the level of process control. Despite 
enormous investments on both supplier and customer sides, 
however, mainframe “central” process control computers 
were never very successful. One reason was the maintenance 
cycle of the mainframe did not fit to that of the plant: there 
was simply too much downtime. An even more important 
reason was that all intelligence had to be programmed into 
the computer. Everything, from the simplest PID control 
algorithm to the most complex control schemes had to be 
written in programming code before it could be executed. 

1950 1960 1975 1990 2003 
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FIG. 2.7 

Development of the distributed control system. 


The complexity of such process control programs was simply 
too high to be practical. 

The first DCS made their entry in the 1970s. Cheap, reli- 
able, and configurable microprocessors made it possible to 
distribute the control over a number of autonomous process 
control modules, each controlling a limited part of the plant. 
Preprogrammed modules to execute a wide variety of pro- 
cess control tasks were now available. In the following years, 
DCSs were used in both continuous and batch applications 
in many different processes. Exposure to different environ- 
ments made them increasingly mature: hundreds of con- 
figurable modules were developed for every possible control 
problem. DCSs also became more specialized. Some were 
more exposed to chemical applications, while others were 
typically used in the electricity market. Some had to con- 
trol complex batch applications with much discrete control, 
while others had to satisfy high demands on historians and 
alarming. 

As time went by, the hardware became ever more reliable. 
Redundant systems were developed on both the process mod- 
ule and communication sides. Soon process controllers were 
able to handle hundreds, even thousands of control loops 
without jeopardizing the reliability of the complete system: 
in reality, the degree of distribution was being constantly 
lowered. DCSs became synonymous for “easy to configure” 
(preprogrammed) but proprietary process control computers 
that fitted perfectly the needs of process control. 

When the fieldbus idea began to get supporters in the 
early 1990s, some control engineers with experience of DCSs 
saw fieldbus standardization as the opportunity to put control 
back in the field. After agreeing on the physical layer (IEC 
61158-2), disagreements in the SP 50 standardization commit- 
tee on the data link layer became so bitter, that the so-called 
“fieldbus wars” broke out. DCS manufacturers supported a 
solution with control in the field while PLC manufacturers 
supported a master-slave solution. Instrument manufacturers 
were caught between two schools and in general adopted the 
fieldbus that their systems partners supported, while remain- 
ing open to the other. The fieldbus primarily associated with 
a DCS is FOUNDATION fieldbus, therefore, although there 
was extreme reluctance to use “control in the field” for many 
years after its introduction [19]. 

Today, DCSs are used to operate processes involving 
batch and continuous control and are often encountered in 
many small and large industries such as oil and gas, food and 
beverage, chemical and pharmaceutical industries. Process 
controllers use PID or a similar control and are not neces- 
sarily reliant on short cycle times. Typical applications are 
ratio control, distillation columns, and control of reactors. 
DCS controllers are normally more expensive than their 
PLC equivalents. Open systems are often equipped with a 
FOUNDATION fieldbus HI interface. The control network 
may be an open standard such as ControlNet, Ethernet/IP, or 
even PROFIBUS DP. The communication network is usually 
Ethernet or an Ethernet-based protocol. Figure 2.8 shows a 
typical DCS architecture. 
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utility network management, telecommunications, etc., in 
fact anywhere where there is a need to monitor and control 
remote equipment. 

Figure 2.9 shows a typical SCADA system, comprising 
four basic components: 

• Master Terminal Unit (MTU) with a HMI: allows 
the operator to view and respond to the data gathered 
from the system. The MTU also provides the central 
processing capability. 

• Remote Terminal Units (RTUs) gather the informa- 
tion from the various sites served by the system. Each 
RTU is connected to sensors and actuators managing 
the local process or equipment. It gathers, stores, and 
sends information to the MTU, which in turn returns 
control commands for the actuators as necessary. 

• Communications network provides the link between 
the MTUs and RTUs in the field. The communica- 
tion can be either wireless (radio, microwave, GMS, 
etc.) or wired, the condition being uninterrupted and 
bidirectional. 

• SCADA software presents the information to the user 
and allows him to intervene in the process. 


FIG. 2.8 

Typical DCS architecture. 

Despite being “easy to configure,” DCS are seldom sold 
as “boxes.” A high level of system knowledge is required, 
which in an age that focuses on core competences, is seldom 
to be found at the customers. Instead, the system will be nor- 
mally sold as part of a project, with the manufacturer or a 
specialist partner being responsible for device integration 
and system configuration. Some DCS salesmen try to exclude 
third-party field devices from a project on the grounds that 
proper functioning cannot be guaranteed. This should be 
taken with a pinch of salt: in reality, there is a great deal of 
cooperation between instrument and system manufacturers 
to ensure the interoperability of their products. Normally, a 
list of all approved and tested field devices will be found on 
the system manufacturer’s website. 

More often than not, the company that installed the sys- 
tem will maintain it as well. In fact, some will not allow the 
customer to do any maintenance at all. For a large system, 
this means that a maintenance team will be permanently on 
site or, alternatively, a means of remote access will have been 
built into the system. In this case, the maintenance team will 
reconfigure the system off-line, then download the new con- 
figuration to the controllers at when the production schedule 
allows. 

SCADA Systems 

SCADA systems have a very long history and are used not 
only in industry but also in building automation, logistics, 


The development of SCADA systems parallels that of the 
DCS, in that the introduction of mainframe computers in the 
1960s saw a boom in their use. At this stage, the MTU was 
responsible for all processing and the issuing of supervisory 
actions, the RTUs acting as slaves. Systems were, however, 
very expensive to operate and maintain. Subsequent develop- 
ment led to more DCS-like structures with RTUs receiving 
the ability to perform actions on their own, without being 
prompted by the MTU. Over the past 20 years, the systems 
have become more open and communication is mostly over a 
closed telemetric or wired network via Ethernet IP. 

SCADA software 
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FIG. 2.9 

Typical SCADA system architecture. 
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SCADA software has also profited from the advance in 
office software. The introduction of object link embedding 
(OLE) for process control, otherwise known as OPC, repre- 
sented a great step forward, allowing a move away from pro- 
prietary to toward open solutions. As discussed at the start 
of this section, modern software packages offer functional- 
ity far beyond that originally envisaged for SCADA systems 
and are now an essential component in all process control 
solutions. 

There are several suppliers offering SCADA software for 
process control applications. Most are open, some packages 
being offered by independent manufacturers and some being 
closely linked to a particular system. In general, SCADA 
software can be purchased separately with a development 
license, which means that purchasers can do their own pro- 
gramming. SCADA users therefore have the choice of pro- 
gramming the application themselves, allowing a system 
integrator do it or to purchase the SCADA system as part of 
an engineering project. If the application is engineered exter- 
nally, the supplier will normally be responsible for mainte- 
nance. This is particularly true for large systems, where even 
small adjustments to the application may involve the recon- 
figuration of a large number of program entities. 

NETWORK SECURITY 

As shown in Figure 2.2, the ideal factory network today pos- 
sesses an open architecture in which information flows hori- 
zontally and vertically across the entire enterprise. Since the 
main communication protocol is Ethernet TCP/IP and the 
company will normally be connected to the World Wide Web, 
security of the network becomes an important issue. The net- 
work cannot be closed down to the outside world, since daily 
business nowadays requires access to Internet, exchange of 
e-mails, etc. Even process control is affected, since nowa- 
days the download of device drivers, software, and firmware 
as well as the distribution of license keys, upgrades, etc., is 
all done via Internet. In addition, companies are increasingly 
outsourcing their engineering and maintenance activities, 
which means the service provider must have 24/7 access to 
the process or devices for which he is responsible. 

A company needs an IT policy, which allows the network 
just enough protection for it to operate efficiently but not so 
much that essential actions cannot be performed. Basically, 
the three network sections, enterprise, plant management, 
and control must be separated from each other by firewalls. 
Similarly, if the company operates a separate data center, this 
must be protected in the same way. It goes without saying 
that any office connection to Internet must also have a fire- 
wall and antivirus protection. Within the company, it makes 
sense to operate the office and plant management networks in 
different Ethernet domains. Not only does this provide more 
security, it also reduces the load on the network. Mixing the 
two, for example, using common PCs and printers, often 
leads to intermittent interruption of communication due to 


timeouts. Finally, access to sensitive data or programming 
functions should be restricted to authorized users. Many 
software applications offer a user management, which does 
just this. For readers interested in more information, there 
are a number of white papers on this subject, for example, 
Ref. [20], and Chapters 30 and 31 discuss network security 
in more detail. 

Network Components 

The components used in building a network are listed in 
Table 2.8 together with a short description of their function. 
It is important to remember, particularly with Ethernet net- 
works, that the quality and robustness required of the compo- 
nents will vary according to where they are used. 

The enterprise level as shown in Figure 2.2 is an office 
network as is found in practically every company today. It 
is built of commercial-off-the-shelf components such as 
switches, routers, hubs and connected together using stan- 
dard Ethernet cables with RJ45 connectors. PCs, printers, 
and other peripheral equipment are built to normal office 
standards. Where the storage of commercial data is con- 
cerned, however, redundant server-grade computers, housed 
in acclimatized rooms, are used. Many large enterprises 
maintain off-site data centers with redundant backup of data, 
often at a second site in a different part of the world. This 
eliminates loss due to power loss, fire, natural disasters, etc., 
and allows the quick recovery of operational status should 
such an event occur. 

At plant management level, we encounter a mixture of 
office and plant conditions. Whereas some companies will 
have an acclimatized control room in which all plant data 
can be viewed on computer monitor or a wall display, others 
will have an operating station in a small office adjacent to the 
production area. Here, more rugged equipment must be used, 
which can withstand dust, vibration, and EMI. Similarly, 
industrial grade Ethernet cables, connectors, switches, etc., 
should be employed. 

Where a dedicated control room is used, the signals 
from the plant will be collected in an adjoining room, oth- 
erwise at some point close to the operating station. Power 
supplies, transmitter power supplies, controllers, couplers, 
links, and other control equipment are usually rack-mounted 
in cabinets with a degree of protection appropriate to their 
location. The cabinet doors may be glass, which allows the 
equipment alarm LEDs or displays to be seen without open- 
ing the doors, or metal. Where the cabinet also serves as a 
local operating station, there is often a display panel mounted 
in the door. The cabinets are wired according to industrial 
guidelines, with strict separation of non-Ex and Ex circuits 
and equipment. In plants using conventional 4-20 m A and 
binary signals, all inputs and outputs are routed into a central 
marshalling rack, before being connected to the controller. 
Fieldbuses usually run direct to the cabinets. 

In a distributed system, controllers and ancillary equip- 
ment such as displays, indicators, etc., may be installed on 
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TABLE 2.8 

Network Components 


Components 

Standards 

Bridges 

Ethernet 

Field devices 

General 

Frequency converters 

General 

Gateways 

General 

Hosts 

Ethernet 

Hubs 

Ethernet 

I/Os 

General 

Interface 

General 

Link (PROFIBUS) 

PROFIBUS 

Linking devices 

FOUNDATION 


fieldbus 

Modems 

General 

Multiplexers 

General 

Ports 

General 

Programmable logic 


controller 


Repeaters 

General 

Routers 

Ethernet 

Remote I/Os 

General 

Segment couplers 

PROFIBUS 

Switches 

Ethernet 

Switching hubs 

Ethernet 


Description 

Device that connects two local area networks (LANs), or two segments of the same LAN that use the same 
protocol. 

Sensor or actuator attached to the process under control. 

Device on a network that serves to control motor drives, etc. 

Device on a network that serves as an entrance to another network. In addition to interfacing physical layer 
and protocols, a gateway may also scan and assemble data for forwarding as a single packet. 

Computer that is connected to a TCP/IP network, including the Internet. Each host has a unique IP address. 

Common connection point for devices in a network with several ports. When a data packet arrives at one 
port, it is copied to the others so that all segments can see it. 

Short for input/output. Device that transfers data, usually in the form of analog or discrete signals, to and 
from a controller. 

Boundary across which two independent systems meet and act on or communicate with each other. 

Device comprising a gateway and one or more segment couplers. 

Device serving as the interface between FOUNDATION fieldbus HI and HSE segments. 

Device to enable transfer of digital data over analog telephone lines or cell telephone networks. 

Device that combines (multiplexes) several signals for transmission over a single medium. Often called a 
MUX. 

Interface on a computer to which a device or network can be connected. 

Device using simple ladder logic or other IEC 61131 programming language to provide real-time control. 

Device used to regenerate or replicate a signal. 

Device that forwards data packets along networks. Routers are located at gateways, that is, the places 
where two or more networks connect. 

I/O device that is not an integral part of the controller, but an independent entity residing within the 
network. 

Device comprising signal coupler, a bus power unit and a PROFIBUS DP/PA interface. 

Device that filters and forwards data packets between local area LAN segments. 

Short for port- switching hub, a special type of hub that forwards data packets to the appropriate port based 
on their address. 


the plant floor close to the process they control. Here spe- 
cial precautions will be taken to protect the equipment from 
vibration, dust, water, and aggressive atmospheres. Control 
equipment will often be found in rugged field enclosures, 
displays will be dust and water-tight. If at all avoidable, 
control equipment will not be mounted in gas and dust haz- 
ardous areas. If there is no alternative, an explosion-proof 
enclosure or similar must be used. Displays, indicators, and 
field devices used in explosion hazardous areas must also 
have the appropriate Ex-certification — the same applies 
to handheld, pocket PCs and computers used to configure 
devices. How the wiring is executed will depend upon the 
Ex-protection concept used in the plant. In the case of intrin- 
sically safe or enhanced safety systems, the cables are routed 
unprotected from control equipment to the devices: special 
cable glands ensure that explosion protection is maintained 
at enclosures and device housings. Explosion-proof junction 
boxes, T-pieces, terminators, etc., are also used. In many 
plants in the United States, the explosion protection concept 
adopted requires that the cables be run in metal or armored 
conduits. 


FIELDBUS NETWORKS 

Readers familiar with the history of digital communication 
in process control will know that work on standardizing an 
international fieldbus for the process industries was started 
in the late 1980s under the auspices of the ISO/ISA SP50 
committee, and that its feasibility was demonstrated by a 
multi-vendor demonstration at both the ISA and Interkama 
exhibitions in 1989. Before the events occurred that caused 
the committee to become the scene of the so-called “field- 
bus wars,” it had been decided that a two-tier structure was 
best suited to the application. At fieldbus level, a bus with 
moderate transmission rates was to offer device power and 
be suitable for use in hazardous locations. This became 
known as HI — “Hunk 1,” referring to the work package! 
“Hunk 2” was the control level requiring faster transmission 
rates, no bus power, and no requirement for use in hazard- 
ous locations. 

The committee standardized the HI physical layer in 
IEC 61158-2 [14], but there was no agreement on the data 
link and application layers, or on the H2 bus. As mentioned 
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earlier, company politics and various other factors caused the 
standardization to grind to a halt. Without going into fur- 
ther details, the result of this stand-off was the emergence of 
the PROFIBUS standards and the setting up of the Fieldbus 
Foundation. Enmity continued for several years until the IEC 
decided to publish both standards, plus a variety of proprie- 
tary systems that were prepared to open their specifications to 
the public, in the IEC 61158 set of standards [14] (see “Types 
1-8“ in Table 2.4). At the same time, the FOUNDATION 
fieldbus standard was published as a European (EN) stan- 
dard [21]. The decision was much criticized, but it has basi- 
cally set up a situation where the user can decide for himself 
which fieldbus “flavor” he prefers. Although the idea of a 
single fieldbus is laudable, in practice there are also different 
demands at field level. In a typical production facility, there is 
a mixture between factory automation (e.g., filling and pack- 
ing) and PA (e.g., batch and continuous), which justifies the 
use of different protocols. 

In the following, those control and fieldbus protocols of 
interest to PA will be briefly introduced. For each, there is a 
brief description of the protocol together with one or more 
typical architectures. An overview of the principle techni- 
cal data is given in Table 2.4. A more detailed description 
of the various fieldbus protocols as well as specific informa- 
tion on the design of networks is included in the following 
sections. 


AS-Interface 

Actuator-sensor interface (AS-i) is primarily a factory auto- 
mation bus for simple binary sensor and actuators operating 
in safe areas. AS-i is supported by a consortium of users and 
manufacturers, which is responsible for development and 
conformance testing [22], Currently, over 280 vendors offer 
AS-i devices or equipment. 

AS-i operates cyclically with a master-slave structure. In 
the standard configuration, the master interrogates all con- 
nected slaves in strict rotation and receives telegrams from 
them. The data structure is extremely simple: AS-i telegrams 
have four output bits that are used to control connected 
devices — to open a valve, or close a switch. A slave answers 
immediately, returning four bits indicating the function per- 
formed. A sensor, for example, a level limit switch returns its 
current status. It is also possible to transmit analog signals 
such as temperature over five cycles, for example, for PID 
control. Alarm interrupts or similar event-controlled mes- 
sages are not provided. Error detection is also much simpli- 
fied and provides only moderate security. Supporting up to 
62 slaves, AS-i has a maximum cycle time of around 5 ms for 
a fully loaded network. 

Figure 2.10 shows a typical architecture. The AS-i bus is 
normally connected to a PLC or PC by an appropriate inter- 
face card. It can also be connected to a control network, for 
example, PROFIBUS DP or DeviceNet, by means of a gate- 
way acting as a master. Power is supplied over the bus. 



FIG. 2.10 

Typical AS-i architecture. 

4-20mA/HART 

HART is primarily a smart protocol, its information being 
transferred point-to-point by superimposing a digital signal 
on a standard 4-20 m A output. The protocol also allows for 
a multi-drop bus structure, however, at the expense of the 
conventional output, that is, in this configuration the current 
signal is locked at 4 mA. HART is supported by the HART 
Communication Foundation [23], an independent body of 
users and vendors who are responsible for development and 
conformity testing. 

HART is basically a single master protocol, which allows 
for a temporary secondary master. This is the case when a 
master reading process data cyclically from the field devices 
and a terminal for device configuration (handheld or laptop) 
are connected to the same segment. Although this situation 
was rare in the past, when the majority of HART devices 
were wired as conventional 4-20 m A devices, today an 
increasing number of controllers offer HART modules that 
make use of the digital communication. 

HART has three classes of command: Universal, com- 
mon practice, and device specific. All HART instruments 
must be able to process commands of the type universal. 
Common practice commands are not mandatory, but when 
they are implemented, the meaning of the commands must 
conform to the specification. In the case of device-specific 
commands, the same designations may have different mean- 
ings in different instruments. As a result, manufacturers 
must supply device description (DD) files if their products 
are to be fully operable in a HART application. If no DD 
is available, operation is restricted to the basic parameters 
encompassed by the universal commands such as the writing 
of zero, span, and damping and the reading of process value 
and status. 

Figure 2.11 shows three typical ways in which HART 
devices are integrated into control system architectures. 
Where a controller uses the HART digital signal, the HART 
devices are connected either point-to-point or as a HART 
multi-drop bus to a HART I/O controller card. In this con- 
figuration, the full parameter set of the device will normally 
be available to the operator via, for example, an OPC server 
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FIG. 2.11 

Typical HART architecture. 

and commissioning/diagnosis of the HART devices is pos- 
sible from a central maintenance station. 

If the HART signal is used only for commissioning/diag- 
nosis, it is more likely that the devices will be connected to 
a remote or intelligent I/O. Remote I/Os are wired point-to- 
point and often provide loop power for the HART/4-20 mA 
devices. Intelligent I/Os may also contain processing abili- 
ties, for example, the ability to link signals from several sen- 
sors to produce a secondary process variable, for example, 
density or mass, or be able to perform simple control actions 
such as closing a valve. Device information is collected by 
the controller or application software via the control network. 
Remote I/Os are often transparent, allowing direct configu- 
ration of the devices by an appropriate maintenance tool. 

Where digital communication is not of interest (except 
perhaps for device configuration via handheld terminal), 
HART devices are connected directly to analog orbinary PLC 
cards via a point-to-point connection. Where the 4-20 mA 
device is loop-powered, the PLC provides the power. If at 
some later point in time, the HART digital signal is required, 
for example, to configure the devices or monitor their read- 
ings from a workstation in the control network, a multiplexer 
may be used. This operates parallel to the conventional point- 
to-point wiring, scanning each of the transmitters in turn and 
storing the measured values and status information in a buf- 
fer. The buffer is accessible to the controller, SCADA, and 
maintenance program over the control network. 

HART is extremely popular and has an enormous installed 
base, although in the majority of cases, the digital signal is not 
used. It has sustained its popularity by successively enhancing 
its protocol with features that the user requires. Where it has 
not been successful is to free itself from its origins as a proto- 
col for pressure transmitters. This means that more complex 
devices such as flow transmitters and analyzers rely heavily 
on device specific parameters for configuration, to the detri- 
ment of interchangeability. In addition, the low transmission 
rate means that the time required for configuration is some 
20-fold that of a standard fieldbus protocol. 


PROFIBUS DP/PROFIBUS PA 

PROFIBUS is an open fieldbus standard. It was developed 
in Germany and was first published as national standard 
in 1992. European Standard EN 50170 followed roughly 
a year later [24]. The application profiles PROFIBUS DP 
(Decentralized Periphery) and PROFIBUS PA, which are 
used in PA, are incorporated in the IEC 61158 standard 
series as Type 3 [14]. In the meantime, a number of other 
profiles have been developed, for example, PROFINET and 
PROFIsafe. More information on PROFIBUS can be found 
in Chapter 40. PROFIBUS is supported by an international 
network of PROFIBUS user organizations, which are also 
responsible for the maintenance of the standards and certifi- 
cation and testing of the devices [25]. 

Figure 2.12 shows a typical PROFIBUS PA network. 
PROFIBUS DP provides the H2 control network backbone 
and PROFIBUS PA the HI fieldbus. The fieldbus is con- 
nected to the control network via a DP/PA coupler or link. 
The controller, usually a PLC, is engineered via the Ethernet 
interface or a laptop computer equipped with a PROFIBUS 
DP card. All other devices, for example, drives, valve posi- 
tioners, and sensors, are PROFIBUS DP or PROFIBUS PA 
slaves. Remote I/Os enable the integration of legacy devices, 
for example, binary, 4-20 m A, HART, and MODBUS 
devices. Operation and maintenance tools communicate with 
the controller via Ethernet. If desired, the data for the main- 
tenance tool can be acquired independently of the controller 
by bypassing it with a gateway. 


Operation Maintenance 



FIG. 2.12 

Typical PROFIBUS architecture. 
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The controller acts as a Class 1 master and communicates 
cyclically or acyclically with the slaves. The gateway and/or 
laptop act as Class 2 masters and communicate acyclically 
with any device, either according to their own schedule or at 
the request of the device. Access to the bus is governed by a 
token passing mechanism, whereby the token holder commu- 
nicates with the devices on a master-slave basis. 

The PROFIBUS standard specifies that each device must 
contain a set of universal parameters. Mandatory parameters 
must always be present. Optional parameters are only present 
when required. Manufacturer-specific parameters are used to 
realize device functions that are not in the standard profile. 
Certification ensures configuration compatibility between 
identical “device types’’ manufactured by different manu- 
facturers, for example, pressure transmitters. Manufacturers 
supply both enhanced device description (EDD) files for 
device configuration and device database files for system 
integration. Should these not be available, devices can still 
be operated, if not fully, by means of the profile parameters 
(mandatory and optional) for the particular device type. 

PROFIBUS has a large installed base covering a vari- 
ety of applications in both factory and process automation 
all over the world. Although it is true to say that its strong- 
hold is still in Europe, there are many important users to be 
found in North America, Southeast Asia, and South Africa. 
Its strengths lie in the amount of vendor support it has, its 
ability to use one protocol for factory and process automa- 
tion, and last but not least the ease with which it fits into PLC 
architectures. 


FOUNDATION FIELDBUS 

FOUNDATION fieldbus is an open fieldbus standard to IEC 
61158, Types 1 and 5 [14], and European Standard EN 50170 
[21] that was developed and is supported by the Fieldbus 
Foundation [26]. It has been designed to solve the measure- 
ment and control tasks associated with PA, aiming to pro- 
vide optimum communication between PLCs or PCS and the 
plant equipment operating on the field level. 

The standard specifies two communication levels. High- 
speed Ethernet (HSE) is the H2 control network on which 
traffic between controllers, computers, frequency convert- 
ers, and other control equipment is handled. FOUNDATION 
fieldbus HI is the fieldbus on which traffic between the pro- 
cess sensors and actuators is handled. HSE uses standard 
Ethernet technology running at a fixed rate of 100 Mbit/s. 
The HI physical layer (wiring and data transfer mecha- 
nism) is based on the international standard IEC 61158-2 
[14], that is, it is exactly the same as PROFIBUS PA. The 
FOUNDATION fieldbus protocol is used for both HSE and 
HI levels. More information on FOUNDATION fieldbus can 
be found in Chapter 39. For more information on HSE see de 
Silva Neto and Berrie [27]. 

The continuous lines in Figure 2.13 show a typical archi- 
tecture as foreseen by the specification. The process is run 
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FIG. 2.13 

Typical FOUNDATION fieldbus architecture. 


by one or more controllers connected to the HSE backbone. 
These may be separate entities or reside in the linking device. 
The engineering tool may be part of the system or may run 
on a separate workstation. Operation and maintenance sys- 
tems run in parallel. FOUNDATION fieldbus HSE handles 
the communication at the control level. Drives, remote I/Os, 
and linking devices, etc., are connected to this bus. At this 
level, the devices are externally powered and HSE ensures 
that data are quickly exchanged. FOUNDATION fieldbus HI 
is used at the field level. The linking device serves as inter- 
face to the HSE system. In addition, a power unit and con- 
ditioner are required to power the field devices over the bus. 
Depending upon power conditioner type, the HI segment can 
be installed in safe or hazardous areas. 

In view of the fact that the HSE specification was pub- 
lished much later than the HI specification, there are at least 
two alternatives to the above architecture, as shown by the 
dotted lines from the controller in Figure 2.13. In one case, 
the FOUNDATION fieldbus HI bus is connected directly to 
the controller or control system via a Fieldbus Foundation HI 
I/O card. In the other field, devices on the HI bus are con- 
nected to the controller network via a bridge (linking device). 
FOUNDATION fieldbus also allows the presence of a visi- 
tor to the HI segment. This might be a handheld for device 
configuration or, as in the figure, a gateway from the HSE 
bus. Such a gateway would allow the use of a field device tool 
(FDT)-based plant asset management (PAM) system inde- 
pendent of type of controller. 

Access to the fieldbus is managed through a determinis- 
tic centralized bus scheduler called the link active scheduler 
(LAS), which resides in the link or a device on the bus. All 
transmissions, whether scheduled or unscheduled, are insti- 
gated at the request of the LAS. Scheduled transmissions are 
used to cyclically transmit process values and control block 
I/O parameters. Unscheduled transmissions are made during 
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the periods when the field devices are executing their func- 
tion blocks or at the end of the CD schedule. The LAS tempo- 
rarily gives device permission to transmit in a client-server 
or source-sink relationship, by sending a pass token mes- 
sage. Table 2.7, gives an overview of the use of the various 
message types. 

FOUNDATION fieldbus is unique in specifying standard 
control blocks, for example, PD, PID, arithmetic, etc., which 
may be implemented in the field devices. Manufacturers sup- 
ply both electronic device description (EDD) files for device 
configuration and device database files common file formats 
(CFF) for system integration. At the time of writing, device 
profiles are being worked on, so at the moment, there is no 
generic operation of particular device types. The system 
engineering tool is used to configure the network and if no 
handheld tool is in use, to set up the devices parameters. 

FOUNDATION fieldbus was later on the market than 
PROFIBUS and suffered from the late introduction of the 
F1SE layer. As a result, support for high-level control equip- 
ment is weak, although the first remote I/Os are being tested. 
Initially, it suffered from interoperability problems because 
only devices and not host systems were tested for confor- 
mance. This has now been remedied, however, and the mar- 
ket has responded accordingly. FOUNDATION fieldbus 
has strong support in North and South America as well as 
Southeast Asia and China. It is beginning to make an impact 
on Europe. Its installed base is in traditional DCS industries 
such as oil and gas and pulp and paper, but it is also penetrat- 
ing water and wastewater and chemicals. Although it offers 
control in the field, and many users see great potential in this 
functionality, most system vendors steer clear of such appli- 
cations and use FOUNDATION fieldbus in a pure “master- 
slave” environment [19]. 


MODBUS 

MODBUS is an industrial standard developed some years ago 
by Gould-Modicon [28] for factory automation applications. 
It is, however, often encountered in PA. Modbus is basically 
a messaging service that may run on a variety of physical lay- 
ers. Two open versions are of interest. Serial MODBUS, using 
RS-485 (or RS-422) as physical layer allows the connection 
of MODBUS devices to a PLC in a bus structure. MODBUS 
TCP (also known as MODBUS TCP/IP) using Ethernet as 
physical layer allows the exchange of data between PECs in 
different networks. 

Figure 2.14 shows typical system architecture. Serial 
MODBUS is connected to the controller via a MODBUS 
card. Bus participants may be MODBUS serial devices or 
gateways that allow the integration of foreign binary and 
analog signals. The controllers communicate with each 
other over Ethernet using the MODBUS TCP protocol. In 
the example shown, the controller also acts as a link to a 
PROFIBUS or FOUNDATION fieldbus network, the val- 
ues being exchanged by special function blocks containing 



FIG. 2.14 

Typical MODBUS architecture. 


mapping tables. The operation is via OPC server. Depending 
upon the components, it may also be possible to use a FDT- 
based tool as the maintenance tool. 

The MODBUS protocol exchanges data in a master-slave 
relationship. Each slave has a unique address, and the data 
are identified by their location in the slave address register. 
Certain characteristics of the MODBUS protocol are fixed, 
such as the frame format, frame sequences, handling of com- 
munications errors, exception conditions, and the functions 
performed. Other characteristics are user selectable; these 
include transmission medium, baud rate, character par- 
ity, number of stop bits, and transmission modes (ASCII or 
RTU). The contents of the data carried by the protocol are 
also freely selectable, that is, nothing is said about strings, 
integers, floating-point numbers, etc. For MODBUS TCP, the 
serial frame is simply inserted into the Ethernet data frame. 
In addition, not all command codes are implemented (see Ref. 
[29]). More details can be found in the MODBUS section. 

MODBUS has a large, worldwide, installed base of over 
seven million points. It remains popular because it is a very 
simple protocol that requires little programming effort to 
get it running. It enjoys extremely good support from system 
manufacturers both on the field, and now on the control net- 
work side. The support for MODBUS TCP by manufacturers 
and users make it a serious contender to become the univer- 
sal “Industrial Ethernet.” 

ControlNet 

ControlNet is an open fieldbus standard to IEC 61158 Type 
2 [14], which was developed as a proprietary protocol by 
Rockwell Automation. It is supported by the Open DeviceNet 
Vendors Association (ODVA) [30], which is now also respon- 
sible for testing and compliance. Essentially, it is control 
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FIG. 2.15 

Typical ControlNet architecture. 


network that shares a common application protocol known 
as common industrial protocol (CIP) with DeviceNet and 
Ethernet/IP. Its installed base is in factory automation, but 
like PROFIBUS DP it crosses the border to PA. In recent 
years, there have been significant advances in integrating 
HART, PROFIBUS, and FOUNDATION fieldbus devices 
at field level via remote I/O or controller cards as well as 
MODBUS TCP at control level. 

Figure 2.15 shows typical system architecture. The 
ControlNet, Ethernet/IP, and DeviceNet networks are con- 
nected to the controller by corresponding cards. ControlNet 
itself allows the connection of remote I/Os, motor control 
centers, drives, etc., and acts as a backbone for control data 
exchange. It also allows the set up of redundant networks. 
Operation and maintenance stations are connected over 
an Ethernet network. Depending upon the application, the 
maintenance tool may use FDT or electronic data sheets 
(EDS), which are the equivalent of DDs in other fieldbus 
systems. 

The ControlNet physical layer uses RG-6 coaxial cable 
with BNC connectors or optical fibers. The network topol- 
ogy is a bus structure with up to 99 participants, with rout- 
ers allowed where necessary. It uses the Manchester coding, 
as do PROFIBUS PA and FOUNDATION fieldbus HI, but 
at a transmission rate of 5 Mbit/s. Similar to PROFIBUS, 
the protocol operates in cycles, whereby each cycle has two 
phases: one for scheduled and one for unscheduled traffic. 


Unscheduled traffic is queued, which means it is not nec- 
essarily transmitted in the cycle in which it is first flagged. 
Unlike PROFIBUS, ControlNet uses the producer-consumer 
(publisher-subscriber) relationships, so that all devices are 
instantaneously aware of any published data that concerns 
them. The application layer is based on the CIP layer and 
supports device profiles. 

ControlNet is important because it has a large installed 
base in a broad range of applications in North America. It 
is also increasing its presence in other parts of the world, 
although the majority of applications are in factory automa- 
tion. DeviceNet and Ethernet/IP also enjoy considerable ven- 
dor support throughout the world. 

Ethernet 

As mentioned in the Introduction, Ethernet has become the 
dominant technology at the operations and, in some cases, 
the control network level. Field-level applications, however, 
are very much confined to factory automation. In general, 
all protocols use the Ethernet physical and data link layers, 
and then impose determinism by various polling or timing 
mechanisms. Detailed information and white papers are 
available at a number of organization websites, including the 
ones below. 

PROFINET [25j is the PROFIBUS Ethernet backbone. 
Although conceived for factory automation, it foresees the 
integration of field devices via PROFINET/ PROFIBUS PA 
linking devices. FOUNDATION fieldbus HSE [26] already 
provides for the integration of fieldbus devices, however, no 
manufacturer has produced one to date. MODBUS TCP [29] 
is already used in PA and seems a likely candidate for field 
devices in hybrid applications requiring fast responses, for 
example, dosing and filling. It is to be expected that devices 
will appear in the near future. Ethernet/IP is supported by 
the ODVA [30] and like MODBUS TCP, it is often used in 
hybrid applications. The first Ethernet/IP flow meter was 
exhibited at the 2009 ISA show. The Ethernet POWERLINK 
Standardization Group [31] supports the use of CANopen 
on Ethernet. With over 450 members and users, the protocol 
provides a solution to machine-based control systems. It is 
unlikely to be used as a protocol for PA. Ethernet for Control 
Automation Technology (EtherCAT) is supported by the 
EtherCAT Technology Group [32] and also orientated toward 
factory automation. It does, however, provide the possibility 
of integrating sensors and actuators via PROFIBUS. Again, 
it is unlikely to be used as a protocol for PA. 

As can be seen, “Ethernet Fieldbus” is still far from 
realization, even though there is considerable pressure from 
users. A lot of the pressure comes from the fact that Ethernet 
equipment is cheap and in ready supply, but is this suit- 
able for field use? There are still a number of questions to 
be answered before “Ethernet Fieldbus” can become reality. 
First, there is the cost and availability of suitable chips. Since 
Ethernet is making considerable advances in factory auto- 
mation, it is to be expected that chips will become cheaper. 
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It is still significant, however, that the first process instru- 
ment with Ethernet/IP interface was a flow meter, a relatively 
expensive instrument. 

Second, there are the information content and response 
times. The standard TCP/IP frame has a minimum length of 
72 bytes. Although the transmission of information across 
the network is fast, the protocol overhead increases the turn- 
around time and hence the response time of the system. At 
present, Ethernet is no match to a binary protocol such as 
AS-i, and in this case, would be definitely more expensive. 
The increase in transmission speed provides little advantage 
where process variables such as temperature and level are 
concerned, because the sensor response time places an upper 
limit on the polling interval. 

Third, there is the (intrinsically safe) powering of the 
devices: Power supply over Ethernet is not an issue, but 
intrinsically safe power is. This is the main reason why IEC 
61158-2 was developed for PA. Any substitute must solve this 
problem before it can penetrate at field level. 

Finally, there is ruggedness. Industrial connectors do 
exist, but other Ethernet equipment, for example, cables, 
switches are seldom designed for an industrial environment. 
An adaptation to, for example, IP 67 or the equivalent NEMA 
rating would cut off the user from the benefits of a mass mar- 
ket and lead to a considerable increase in price. Here again, 
the development of Ethernet in factory automation might 
help lower the price. 

Summing up, at the time of writing the first steps 
in implementing Ethernet at field level have been made. 
Whether a complete range of “Ethernet Fieldbus” instrumen- 
tation becomes available depends very much on whether an 
economical solution for hazardous areas can be found. 

Wireless 

As wireless solutions for PA, WirelessHART and ISA 
SPlOO.lla will be integrated into existing control networks. 
Both are foreseen for applications such as process monitoring, 
plant asset management, and inventory control. Automation 
applications of category three, open-loop control (man in 
the loop), are also feasible. As mentioned previously, both 
share a common physical and data link layer. Whereas the 
WirelessHART application layer is trimmed to the HART 
7.0 specification, which was written exclusively for it, ISA 
SPlOO.lla supports several fieldbus protocols. Whether 
WirelessHART and ISA SPlOO.lla HART are entirely com- 
patible remains to be seen. 

Figure 2.16 shows two basic architectures for wireless 
sensor networks. Both standards allow the integration of the 
wireless network over Ethernet. Depending on the gateway, 
other interfaces may be possible, for example, RS-485. For 
WirelessHART, the gateway buffers the process data, which 
are sent regularly in burst mode from the devices, and makes 
them available to an OPC server. Configuration and mainte- 
nance is possible by FDT, EDDL, and depending on gateway, 
by web server. For ISA SPlOO.lla, a second possibility of 



FIG. 2.16 

Typical Wireless architecture. 

integrating the wireless gateway directly onto the fieldbus 
network is foreseen, in our example, PROFIBUS DP. 

FIELD INSTRUMENTATION 

Having discussed the various aspects of control networks, 
what about the field instrumentation with which they are 
populated? Bagajewicz [33] in the third Edition, Process 
Software and Digital Networks, of the IEH book discussed 
instrument selection from the point of view of price, perfor- 
mance, and redundancy. Da Silva Neto and Berrie [34] have 
pointed out that if a fieldbus device is chosen in preference 
to a conventional one, it makes economic sense to use the 
features it offers. This is particularly true of HART devices, 
where the use of digital communication for anything else 
but parameterization seems more of an afterthought than a 
planned action. For this section, however, two aspects of field 
device selection will be considered: safety integrity level and 
use in hazardous areas. 

Safety Integrity Level 

Safety integrity level has become very important in the pet- 
rochemical. hazardous chemical, and related industries since 
the publication of IEC 61508 [35], which set out new require- 
ments for the assessment of safety functions within a pro- 
duction plant. This was followed by the publication of IEC 
61511 [36], which is an adaptation of IEC 61508 for use in the 
process industry sector. ANSI/ISA 83.00.01-2004 [37] is the 
American adaption of the same standard. 

The standard defines Safety Integrity Level as the rela- 
tive level of risk provided by a safety function. There are 
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four safety integration levels (SIL): SIL1 to SIL4, SIL4 
being the most dependable. The requirements are grouped 
into two broad categories: hardware safety integrity and sys- 
temic safety integrity. For a fieldbus-based safety function to 
achieve a safety rating of say SIL2, both the protocol and the 
device must achieve this level. NAMUR Recommendation 
NE97 [38] sets requirements for the design and operation of 
secure fieldbus topologies and since its publication in 2003, 
many fieldbus organizations have sought to implement it. 

PROF1BUS developed PROFIsafe and the correspond- 
ing General Station Description (GSD) files for factory auto- 
mation in 2004 and, depending upon application, achieves 
a level as high as S1L3. FOUNDATION fieldbus recently 
completed field trails where a level between SIL2 and SIL3 
was obtained; however, the “FF-SIS” specification has still 
to be officially incorporated into the standard. The ODVA 
has developed the CIP to a level of SIL3, as has MODBUS. 
FIART has not developed a safety protocol, and although 
there are FIART devices and equipment on the market, which 
have been certified to S1L3, this is because they basically use 
the 4-20 mA signal only and block off the digital communi- 
cation to the system. 

Hazardous Areas 

Since many fieldbuses must operate in hazardous areas, 
the simpler this is to implement, the more cost-effective is 
their use. All of the fieldbuses discussed above offer a con- 
cept for operation in explosion hazardous areas. Most make 
use of barriers that may be stand-alone or integrated into 
a remote I/O and that allow the connection of intrinsically 
safe devices, although the field device itself may operate 
with a different protocol, for example, MODBUS/FIART. 
In the case of HART devices, it is important that the con- 
nection is transparent; otherwise the digital communication 
will be blocked. ControlNet, which uses coaxial or glass 
fiber cable, offers a complete range of components, which 
when used according to the manufacturer’s instructions 
regarding bus length, tap length, and taps makes up to a 
certified system. 

PROFIBUS PA and FOUNDATION fieldbus HI, which 
supply bus power over the network, offer two concepts 
for installation in explosion hazardous areas. Fieldbus 
Intrinsically Safe COncept (FISCO) standardized in IEC 
60050-27 [29] and Fieldbus Nonlncendive Concept, (FNICO). 
The FISCO concept, which is part of the PROFIBUS PA 
standard, lays down the requirements for bus coupler/linking 
device, cable, bus length, tap length and maximum allow- 
able current. When the bus is designed according to these 
criteria and all components are FISCO certified, the whole 
can be seen as Ex-approved for Zone 0 or Zone 1 without 
applying the entity concept. FNICO was developed when 
it was realized that many devices were working in Zone 2, 
where a hazard may occur only occasionally. FNICO works 
at higher powers than FISCO, thus allowing more devices 
per segment. 


INTEGRATION OF PROCESS VARIABLES 

If a process facility has a proprietary PCS installed, the 
problem of device integration will have been solved by the 
system vendor. This is done, however, at the expense of free- 
dom of choice regarding the sensors, actuators, and auxil- 
iary equipment as well as flexibility in system design. Being 
locked into a particular system can also be expensive. Open 
systems, on the other hand, allow the user to choose best in 
class devices and components or simply ensure that the best 
performance is being bought for the budget at hand. How 
can it be ensured that the system works, however, especially 
in times such as these when many manufacturers have out- 
sourced their engineering departments and lost valuable 
knowledge? 

Device Integration 

Field devices with a digital communication interface must 
be integrated into the control system before they can be 
operated. For HART, the manufacturer provides a Device 
Description (DD) and for PROFIBUS and FOUNDATION 
fieldbus, an EDD with each device, which tells the operat- 
ing software which parameters the device contains and how 
incoming data are to be interpreted. For PROFIBUS and 
FOUNDATION fieldbus, a second network configuration 
file, the GSD file or CFF file is required: this tells the system, 
for example, what commands and transmission rates are sup- 
ported and which measured values can be sent over the bus. 
For Ethernet/IP the DD and network configuration file are 
combined into a so-called EDS. MODBUS requires no inte- 
gration files: the user must know only the registers in which 
the input and output data are stored. 

DDs were developed in the early 1990s to describe rela- 
tively simple devices. Over the years, it has become increas- 
ingly difficult to adequately describe all device functions 
with a DD, especially when it was to be used with an asset 
management tool. For this reason, the EDD was developed, 
which provides more flexibility. 

DDs are dependent upon protocol and the system into 
which they are to be integrated. It is very important, there- 
fore, that when choosing a device for a particular fieldbus 
and system, that the correct DDs are used. First, they should 
have been tested and approved by the user group responsible; 
second, where special features are required for particular 
systems, they should have been tested and approved by both 
instrument manufacturer and system vendor. In recent years, 
there has been increased awareness of user problems regard- 
ing integration and many manufacturers now cooperate in 
testing and publishing DD downloads for specific systems. 
DDs and EDDs for general use can be downloaded from the 
user group websites. 

GSD and CFF files operate in all PROFIBUS or 
FOUNDATION fieldbus control systems, although there 
was a case where a particular PROFIBUS segment coupler 
required modified GSD file. Although the coupler is no 
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longer on the market, these files are part of the standard GSD 
download set. 

Interchangeability of Devices 

The replacement of field devices by others from the same 
or a different manufacturer often causes problems. Devices, 
protocols, and tools all evolve over the years, and informa- 
tion on which device version is supported by which tool ver- 
sion is not always available. Generally, most protocols and 
tools are backward compatible, that is, older device versions 
can be run with newer protocol/tool versions, but not vice 
versa. In this case, new drivers (EDD, GSD, CFF, etc.) must 
be installed in the system before the substitute device can be 
operated. For devices from the same manufacturer, provided 
the structure of the parameter set structure has not changed, 
the device should run. 

For substitutions involving devices from other manufac- 
turers, the degree of integration associated with a particular 
fieldbus protocol has a great deal of influence on how easily 
a device can be replaced. As, in the majority of cases, HART 
devices are connected to the controller by the 4-20 mA sig- 
nal and digital communication is used only to parameterize 
with a handheld, the HART protocol has the lowest degree of 
integration and devices can be easily exchanged. If, however, 
the device is to be configured from a PAM tool, its DD or 
device type manager (DTM) must be available. 

PROFIBUS has a higher degree of integration: the substi- 
tute device must deliver the same measured values over the 
bus as the original one. PROFIBUS defines device profiles, 
which specify which data should be exchanged, but every 
manufacturer can go beyond this. If manufacturer-specific 
values are used in the application, then any replacement 
device must offer the same value set, or the system must be 
reconfigured. 

The highest degree of integration is exhibited by 
FOUNDATION fieldbus. Here, the system knows not only 
the entire parameter set of all the devices in the network, 
but also all the function blocks in use and the links between 
them. Function blocks are classified as standard, enhanced, 
and customized. Only devices using standard blocks are 
truly interchangeable, enhanced and customized may contain 
parameters and links that a substitute device may not have. 
Such a substitution would require the reengineering of the 
control strategy. 

Engineering 

A control system is configured by an engineering tool, which 
will normally have a set of DDs and network configuration 
files already available. Normally, the control strategy will 
be programmed off-line. All fieldbus devices are assigned 
an address, which may be set by software or hardware or 
automatically generated from the identification data of the 
device. It is also decided what measured values are to be sup- 
plied by which devices. For example, for MODBUS, this is 


determined by the register address, for PROFIBUS by the 
parameters configured for transmission over the bus, and for 
FOUNDATION fieldbus by the linking of the input and out- 
put values of the function blocks. 

The commissioning and testing of the system is done on 
site after the real devices have been installed. When the engi- 
neering tool goes on line, that is, is connected to the control- 
ler and network, the devices in the network can be seen in 
a so-called live list. Virtual devices in the off-line configu- 
ration are assigned to the real devices, either automatically 
through their address, or through selection in a menu. At this 
stage, most systems will check the compatibility of the DD 
and network configuration files, and if necessary, new ones 
can be downloaded. When everything has been assigned cor- 
rectly, the complete control strategy is downloaded to the 
controller(s) and the program runs. 

OPC Server 

The system is normally operated from an operator console, 
which provides a graphical display of the plant and allows 
the operator to intervene in the process when required. The 
display is provided by SCADA software, the process values 
and other parameters to be seen being acquired from one or 
more so-called OPC servers. The control system publishes 
its parameters to the OPC server at regular intervals, and the 
display is continuously updated, allowing a quasi-real time 
displays of the plant status. 

OPC is a series of specifications based on basic PC stan- 
dards and COM-DCOM technology, which provides open 
connectivity in industrial automation and enterprise systems. 
The standards are created, maintained, and adapted to new 
technologies by the OPC Foundation, a user group that owns 
the technology and provides compliance testing [40], The 
original OPC standard, covering data access, was the result 
of collaboration between a consortium of system vendors and 
Microsoft. It defined a standard set of objects, interfaces, and 
methods that provided a simple means of ensuring interoper- 
ability of process and factory automation applications. This 
framework allowed a large number of software products to 
be developed, which ensure seamless data exchange through- 
out the factory network. 

Before the development of the OPC specification, a 
special driver had to be written if one application on a net- 
work, for example a controller, was to exchange data with 
another, for example, a SCADA software application. Since 
no two controllers handled data in exactly in the same way, a 
SCADA supplier had to supply a driver for every controller on 
the market. In practice, this did not happen, so the user was 
restricted in her/his choice. By installing standardized OPC 
interfaces in both components, only one driver was required 
and data could be exchanged in a client (SCADA) — server 
(controller) relationship. This technology is not restricted to 
controllers however, and other control devices such as remote 
I/Os, gateways, or even field devices can publish data in the 
same manner. 


© 2012 by Bela Liptak 



68 Process Control and Automation 


The original standard regulated the acquisition of pro- 
cess data, but it was quickly realized that other types of data 
could benefit from standardization. These included data 
access, alarms and event handling, and XML data in held 
devices. The latest standard OPC UA (United Architecture) 
is concerned with a change of platform from COM-DCOM 
to SOA technology. 

Plant Asset Management 

The parameterization of a held device, as well as the check- 
ing of device status, is often done in an application that runs 
separately from the operating software, although the results 
may be displayed at the same console. Such PAM programs 
may be associated with a control system, for example, 
Siemens PDM or Emerson AMS or they may be built on the 
open FDT standard series IEC 62453 [41]. PAM systems also 
allow the regular monitoring of safety or production critical 
with a view to predicting the need for maintenance or avoid- 
ing failure in service. 

System-based tools often use DDs (or their equivalents) as 
the basis for operation of the devices. As pointed out earlier, 
DDs do not necessarily map all the functions of a device — 
a case in point being the display of the envelope curve of a 
time-of-Oight level device, which is used to tune the trans- 
mitter to the application. FDT was developed to overcome 
these shortcomings and provide an open interface for asset 
management, independent of protocol. EDDs were devel- 
oped after FDT technology came available on the market, 
as a means of obtaining the enhanced functionality of FDT 
without having to abandon the original DD -based platform. 

Prime mover in the case of FDT was the PROFIBUS 
User Organization. The idea was to define a set of protocol- 
independent interface standards for the exchange of device 
configuration and later asset management data throughout 
the control network (see Figure 2.17). Each intelligent device 


in the network is supplied with a so-called DTM, which con- 
tains both the parameters and the operating interface for full 
device configuration. The DTM runs in an FDT frame pro- 
gram. There are two types: Device DTMs for field devices 
and CommDTMs for communication devices, for exam- 
ple, gateways or remote I/Os. Transparent communication 
devices requiring no configuration, couplers, for example, 
require no DTM. 

The FDT standard ensures that all DTMs run in all 
FDT frame programs. Responsibility for the production of 
the DTM lies with the manufacturers, who together with 
user, has the guarantee that it will run in all systems that are 
FDT compliant. A DTM offered by a manufacturer is either 
developed specially or generated from an existing HART, 
PROFIBUS, or FOUNDATION fieldbus device description 
(DD or EDDL). If a manufacturer does not provide a native 
DTM, a so-called iDTM may be used to interpret the device’s 
DD or EDDL. At the time of writing, iDTMs exist for HART 
and FOUNDATION fieldbus devices. PROFIBUS devices 
can be configured by means of profile DTMs. Since FDT 
essentially frees device operation from protocol dependent 
factors, it also provides seamless data flow across networks 
in which different protocols are operating. 

2007 saw the establishment of the FDT Group [42], which 
is responsible for developing, maintaining, and testing com- 
pliance to the standard. At the time of writing, 72 compa- 
nies worldwide are actively involved in the group, many with 
DTMs or FDT frame tools on the market. CommDTMs are 
available for Ethernet, PROFIBUS, HART, FOUNDATION 
fieldbus MODBUS, and a number of other protocols. 
Device DTMs are available for HART, PROFIBUS, and 
FOUNDATION fieldbus. Where FDT really has an advan- 
tage is in is support from factory automation. This not only 
provides it with CommDTMs for a wide variety of interfaces, 
it also means that controllers, motor control centers, low volt- 
age switch gear, etc., can all be operated from a single tool. 


Maintenance 



FOUNDATION fieldbus PROFIBUS PA HART FOUNDATION fieldbus PROFIBUS PA HART 


FIG. 2.17 

Protocol independent operation with FDT technology. 
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2007 also saw the announcement by the FDT group and 
supporters of EDDL that they would both cooperate in the 
development of a new field device integration (FDI) standard, 
which would provide even better integration and support 
migration from FDT/EDDL to FDI. 

NET-WIDE DATA EXCHANGE 

Up to now, this section has been concerned with the distribu- 
tion around the enterprise of measured values and the infor- 
mation that can be derived from them. There are a number of 
other “visions” of the “digital factory,” some partially real- 
ized, which might at some point or other have a profound 
influence on the way devices are designed and the informa- 
tion they carry. This section takes a look at three aspects: 
STEP, Product Attributes, and XML. 

Step 

One of the main reasons for developing open interfaces was 
to facilitate the exchange of office data such as documents, 
drawings, data bank information, etc. It might be said that 
thanks to the dominant position of Microsoft, this problem 
no longer exists, but in fact many of the programs used in 
process engineering have been developed by specialist 
companies. Thus, there is often no interface between P&I 
diagram, the associated specifications sheet, the engineer- 
ing tool, which will add the control to the process and the 
plant documentation. The result is that drawings and text are 
redrawn and retyped many times over by manufacturer and 
customer alike. 

The Standard for the Exchange of Product Model Data 
(STEP), ISO 10303 [43], initiative aims to solve this prob- 
lem. Although often claimed to be dead, it is well advanced 
within the oil and gas and also finds supports in some chemi- 
cal companies. STEP aims to introduce standard exchange 
formats for all items that are interchanged within the life 
cycle of a plant, for example, P&I diagrams, electrical instal- 
lation diagrams, functional data, equipment specifications, 
etc. Among other things, this entails producing a data model 
of the entire plant, each entity being described by its attri- 
butes and relationships to other objects. Although the major- 
ity of items will be exchanged between the plant management 
and the enterprise level, some of the data concerns the field 
devices themselves. 

One result of STEP could be that life cycle data must 
be made available when a device is addressed in a SCADA 
software or maintenance program. This requires standard 
structures and terminology: the same parameters must have 
the same names and appear at the same position within a 
data structure, irrespective of vendor. The IEC 61987 Part 10 
onward and IEC 61360 [44,45], or indeed the FOUNDATION 
fieldbus and PROFIBUS PA function blocks, may provide a 
basis. If the data content of field devices can be standardized, 
this opens the way for much simpler integration into software 


tools at both control and plant management levels; a step that 
will lead to more openness throughout the company network. 

Product Attributes 

IEC 61987 Part 1 set out to provide a common structure 
for data sheets, which could be exchanged by means of 
SGML. In IEC 61987 Part 10, published in 2009, this idea 
was extended further by defining lists of properties (LOPs) 
comprising blocks and attributes, which together comprise 
a property dictionary built up according to IEC 61360. An 
operative LOPs lays down the conditions at the measuring 
point and a device LOPs describes the device that fits the 
conditions. As data are exchanged between user and vendor, 
additional properties such as device configuration, tag and 
serial number could be added, so when the device is deliv- 
ered, the user has all the device data in a format that can be 
integrated into his engineering tool. 

The standard aims to provide various LOP aspects, 
including ones covering the ISA SP20 data sheets [46] and 
PROLIST [47]. Agreements have been made with PROFIBUS 
International and the Fieldbus FOUNDATION about the use 
of their device parameter sets. It is possible that in future this 
standard will provide a method of pre-configuring fieldbus 
devices, which would greatly simplify their integration into 
fieldbus systems. IEC 61987 is an ambitious project and over 
the next 3 years will provide LOPs for a great variety of pro- 
cess devices. It is compatible with STEP, and uses a modified 
version of the STEP library as its device-type dictionary. XML 
(see the following text) is one possibility for exchange of data. 

XML 

XML stands for Extensible Markup Language and is a text 
markup language that, in functionality and simplicity, lies 
somewhere between its parent SGML, which was standard- 
ized in the 1970s, and HTML. It is designed to carry struc- 
tured textual information independent of style information. 
HTML differs, because style information, for example, font 
and font size is carried by predefined tags within the file. 
XML does not have predefined tags, and uses a document 
type definition (DTD) or an XML Schema to describe the 
data held in an XML file. Readers familiar with DD technol- 
ogy will immediately recognize the similarities between the 
two technologies: a TXT file, DD or XML, carries the data 
and the type definition, device or document, respectively, 
interprets them. 

Separating data content from the way in which it is dis- 
played ensures that any change to one does not affect the 
other. This leads to several interesting applications in PA. 
XML data can be published in HTML pages provided by a 
web server, and read by a local browser — already used by 
some web configuration tools. XML data can be transmitted 
together with their DTD across the Internet or control network 
and read directly by, for example, Microsoft Office programs 
such as Excel, etc., which support XML data exchange — this 
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allows the information carried by measured value and alarm 
e-mails from field devices or gateways to be stored in data- 
bases. An OPC server is capable of taking the XML data and 
storing it for use by an HMI or SCADA software application. 
Storage and retrieval programs are easily written and generic 
applications can be used to display the data. XML can also 
be used for exchange of data between control and enterprise 
systems as well as for B2B applications. 

Finally, moves are afoot to bring XML into the field 
devices themselves. This could mean that eventually, all the 
parameters and information held within a fieldbus device 
would be structured in the same manner, with the same tags, 
independent of vendor and protocol. Only the communica- 
tion across the network would be protocol dependent, and 
when the features of FDT technology are considered, even 
this will play a minor role in the future. 

CONCLUSIONS 

Flaving seen the progress made in fieldbus technology since 
the last edition of this book, it would be appropriate at this 
point if the authors could look into the future. Unfortunately, 
this is not possible. There are, however, certain trends observ- 
able, which will probably have a great influence on the con- 
trol system of the future: 

• Field devices are becoming increasingly important as 
a source of information for plant and EAM systems. 
The standards are already in position, and vendors 
will adapt their systems to allow free flow of informa- 
tion from field to enterprise level. For some applica- 
tions, it will prove advantageous to bypass the control 
system and tap the data at source. 

• As plant and EAM grow in importance, the influ- 
ence of IT on control system design will increase. 
The databases behind the system will become stan- 
dardized, and proprietary systems will move toward 
openness. 

• As protocol-dependent factors are eliminated from the 
system database, the role of the protocol in control and 
asset management systems will become less. OPC, 
XML, and FDT are already eroding its influence, 
cooperation between then will eliminate it completely. 

• Web technologies have established themselves in 
remote monitoring applications. The embedding of 
sequential or continuous control in “Plant Access 
Points” utilizing this technology will open a new era 
of “Microcontrol,” where size and control capability 
will be exactly matched to the task at hand. 

There are, of course, a great number of other factors that 
influence the development of both networks and the protocols 
that are used on them. Perhaps the future is different — but we 
will have to wait until the next edition of the IEH before we 
know for certain. 
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